home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2131 < prev    next >
Text File  |  1997-04-07  |  114KB  |  2,524 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           R. Droms
  8. Request for Comments: 2131                           Bucknell University
  9. Obsoletes: 1541                                               March 1997
  10. Category: Standards Track
  11.  
  12.                   Dynamic Host Configuration Protocol
  13.  
  14. Status of this memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    The Dynamic Host Configuration Protocol (DHCP) provides a framework
  25.    for passing configuration information to hosts on a TCPIP network.
  26.    DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the
  27.    capability of automatic allocation of reusable network addresses and
  28.    additional configuration options [19].  DHCP captures the behavior of
  29.    BOOTP relay agents [7, 21], and DHCP participants can interoperate
  30.    with BOOTP participants [9].
  31.  
  32. Table of Contents
  33.  
  34.    1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  2
  35.    1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . .  3
  36.    1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . .  4
  37.    1.3 Problem definition and issues . . . . . . . . . . . . . . . .  4
  38.    1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . .  5
  39.    1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  6
  40.    1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . .  6
  41.    2.  Protocol Summary. . . . . . . . . . . . . . . . . . . . . . .  8
  42.    2.1 Configuration parameters repository . . . . . . . . . . . . . 11
  43.    2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
  44.    3.  The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
  45.    3.1 Client-server interaction - allocating a network address. . . 13
  46.    3.2 Client-server interaction - reusing a  previously allocated
  47.        network address . . . . . . . . . . . . . . . . . . . . . . . 17
  48.    3.3 Interpretation and representation of time values. . . . . . . 20
  49.    3.4 Obtaining parameters with externally configured network
  50.        address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
  51.    3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
  52.    3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
  53.    3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
  54.    4.  Specification of the DHCP client-server protocol. . . . . . . 22
  55.  
  56.  
  57.  
  58. Droms                       Standards Track                     [Page 1]
  59.  
  60. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  61.  
  62.  
  63.    4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
  64.    4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
  65.    4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
  66.    4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
  67.    5.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
  68.    6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .42
  69.    7.  Security Considerations. . . . . . . . . . . . . . . . . . . .43
  70.    8.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
  71.    A.  Host Configuration Parameters  . . . . . . . . . . . . . . . .45
  72. List of Figures
  73.    1. Format of a DHCP message . . . . . . . . . . . . . . . . . . .  9
  74.    2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
  75.    3. Timeline diagram of messages exchanged between DHCP client and
  76.       servers when allocating a new network address. . . . . . . . . 15
  77.    4. Timeline diagram of messages exchanged between DHCP client and
  78.       servers when reusing a previously allocated network address. . 18
  79.    5. State-transition diagram for DHCP clients. . . . . . . . . . . 34
  80. List of Tables
  81.    1. Description of fields in a DHCP message. . . . . . . . . . . . 10
  82.    2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
  83.    3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
  84.    4. Client messages from various states. . . . . . . . . . . . . . 33
  85.    5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
  86.  
  87. 1. Introduction
  88.  
  89.    The Dynamic Host Configuration Protocol (DHCP) provides configuration
  90.    parameters to Internet hosts.  DHCP consists of two components: a
  91.    protocol for delivering host-specific configuration parameters from a
  92.    DHCP server to a host and a mechanism for allocation of network
  93.    addresses to hosts.
  94.  
  95.    DHCP is built on a client-server model, where designated DHCP server
  96.    hosts allocate network addresses and deliver configuration parameters
  97.    to dynamically configured hosts.  Throughout the remainder of this
  98.    document, the term "server" refers to a host providing initialization
  99.    parameters through DHCP, and the term "client" refers to a host
  100.    requesting initialization parameters from a DHCP server.
  101.  
  102.    A host should not act as a DHCP server unless explicitly configured
  103.    to do so by a system administrator.  The diversity of hardware and
  104.    protocol implementations in the Internet would preclude reliable
  105.    operation if random hosts were allowed to respond to DHCP requests.
  106.    For example, IP requires the setting of many parameters within the
  107.    protocol implementation software.  Because IP can be used on many
  108.    dissimilar kinds of network hardware, values for those parameters
  109.    cannot be guessed or assumed to have correct defaults.  Also,
  110.    distributed address allocation schemes depend on a polling/defense
  111.  
  112.  
  113.  
  114. Droms                       Standards Track                     [Page 2]
  115.  
  116. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  117.  
  118.  
  119.    mechanism for discovery of addresses that are already in use.  IP
  120.    hosts may not always be able to defend their network addresses, so
  121.    that such a distributed address allocation scheme cannot be
  122.    guaranteed to avoid allocation of duplicate network addresses.
  123.  
  124.    DHCP supports three mechanisms for IP address allocation.  In
  125.    "automatic allocation", DHCP assigns a permanent IP address to a
  126.    client.  In "dynamic allocation", DHCP assigns an IP address to a
  127.    client for a limited period of time (or until the client explicitly
  128.    relinquishes the address).  In "manual allocation", a client's IP
  129.    address is assigned by the network administrator, and DHCP is used
  130.    simply to convey the assigned address to the client.  A particular
  131.    network will use one or more of these mechanisms, depending on the
  132.    policies of the network administrator.
  133.  
  134.    Dynamic allocation is the only one of the three mechanisms that
  135.    allows automatic reuse of an address that is no longer needed by the
  136.    client to which it was assigned.  Thus, dynamic allocation is
  137.    particularly useful for assigning an address to a client that will be
  138.    connected to the network only temporarily or for sharing a limited
  139.    pool of IP addresses among a group of clients that do not need
  140.    permanent IP addresses.  Dynamic allocation may also be a good choice
  141.    for assigning an IP address to a new client being permanently
  142.    connected to a network where IP addresses are sufficiently scarce
  143.    that it is important to reclaim them when old clients are retired.
  144.    Manual allocation allows DHCP to be used to eliminate the error-prone
  145.    process of manually configuring hosts with IP addresses in
  146.    environments where (for whatever reasons) it is desirable to manage
  147.    IP address assignment outside of the DHCP mechanisms.
  148.  
  149.    The format of DHCP messages is based on the format of BOOTP messages,
  150.    to capture the BOOTP relay agent behavior described as part of the
  151.    BOOTP specification [7, 21] and to allow interoperability of existing
  152.    BOOTP clients with DHCP servers.  Using BOOTP relay agents eliminates
  153.    the necessity of having a DHCP server on each physical network
  154.    segment.
  155.  
  156. 1.1 Changes to RFC 1541
  157.  
  158.    This document updates the DHCP protocol specification that appears in
  159.    RFC1541.  A new DHCP message type, DHCPINFORM, has been added; see
  160.    section 3.4, 4.3 and 4.4 for details.  The classing mechanism for
  161.    identifying DHCP clients to DHCP servers has been extended to include
  162.    "vendor" classes as defined in sections 4.2 and 4.3.  The minimum
  163.    lease time restriction has been removed.  Finally, many editorial
  164.    changes have been made to clarify the text as a result of experience
  165.    gained in DHCP interoperability tests.
  166.  
  167.  
  168.  
  169.  
  170. Droms                       Standards Track                     [Page 3]
  171.  
  172. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  173.  
  174.  
  175. 1.2 Related Work
  176.  
  177.    There are several Internet protocols and related mechanisms that
  178.    address some parts of the dynamic host configuration problem.  The
  179.    Reverse Address Resolution Protocol (RARP) [10] (through the
  180.    extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
  181.    addresses the problem of network address discovery, and includes an
  182.    automatic IP address assignment mechanism.  The Trivial File Transfer
  183.    Protocol (TFTP) [20] provides for transport of a boot image from a
  184.    boot server.  The Internet Control Message Protocol (ICMP) [16]
  185.    provides for informing hosts of additional routers via "ICMP
  186.    redirect" messages.  ICMP also can provide subnet mask information
  187.    through the "ICMP mask request" message and other information through
  188.    the (obsolete) "ICMP information request" message.  Hosts can locate
  189.    routers through the ICMP router discovery mechanism [8].
  190.  
  191.    BOOTP is a transport mechanism for a collection of configuration
  192.    information.  BOOTP is also extensible, and official extensions [17]
  193.    have been defined for several configuration parameters.  Morgan has
  194.    proposed extensions to BOOTP for dynamic IP address assignment [15].
  195.    The Network Information Protocol (NIP), used by the Athena project at
  196.    MIT, is a distributed mechanism for dynamic IP address assignment
  197.    [19].  The Resource Location Protocol RLP [1] provides for location
  198.    of higher level services.  Sun Microsystems diskless workstations use
  199.    a boot procedure that employs RARP, TFTP and an RPC mechanism called
  200.    "bootparams" to deliver configuration information and operating
  201.    system code to diskless hosts.  (Sun Microsystems, Sun Workstation
  202.    and SunOS are trademarks of Sun Microsystems, Inc.)  Some Sun
  203.    networks also use DRARP and an auto-installation mechanism to
  204.    automate the configuration of new hosts in an existing network.
  205.  
  206.    In other related work, the path minimum transmission unit (MTU)
  207.    discovery algorithm can determine the MTU of an arbitrary internet
  208.    path [14].  The Address Resolution Protocol (ARP) has been proposed
  209.    as a transport protocol for resource location and selection [6].
  210.    Finally, the Host Requirements RFCs [3, 4] mention specific
  211.    requirements for host reconfiguration and suggest a scenario for
  212.    initial configuration of diskless hosts.
  213.  
  214. 1.3 Problem definition and issues
  215.  
  216.    DHCP is designed to supply DHCP clients with the configuration
  217.    parameters defined in the Host Requirements RFCs.  After obtaining
  218.    parameters via DHCP, a DHCP client should be able to exchange packets
  219.    with any other host in the Internet.  The TCP/IP stack parameters
  220.    supplied by DHCP are listed in Appendix A.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Droms                       Standards Track                     [Page 4]
  227.  
  228. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  229.  
  230.  
  231.    Not all of these parameters are required for a newly initialized
  232.    client.  A client and server may negotiate for the transmission of
  233.    only those parameters required by the client or specific to a
  234.    particular subnet.
  235.  
  236.    DHCP allows but does not require the configuration of client
  237.    parameters not directly related to the IP protocol.  DHCP also does
  238.    not address registration of newly configured clients with the Domain
  239.    Name System (DNS) [12, 13].
  240.  
  241.    DHCP is not intended for use in configuring routers.
  242.  
  243. 1.4 Requirements
  244.  
  245.    Throughout this document, the words that are used to define the
  246.    significance of particular requirements are capitalized.  These words
  247.    are:
  248.  
  249.       o "MUST"
  250.  
  251.         This word or the adjective "REQUIRED" means that the
  252.         item is an absolute requirement of this specification.
  253.  
  254.       o "MUST NOT"
  255.  
  256.         This phrase means that the item is an absolute prohibition
  257.         of this specification.
  258.  
  259.       o "SHOULD"
  260.  
  261.         This word or the adjective "RECOMMENDED" means that there
  262.         may exist valid reasons in particular circumstances to ignore
  263.         this item, but the full implications should be understood and
  264.         the case carefully weighed before choosing a different course.
  265.  
  266.       o "SHOULD NOT"
  267.  
  268.         This phrase means that there may exist valid reasons in
  269.         particular circumstances when the listed behavior is acceptable
  270.         or even useful, but the full implications should be understood
  271.         and the case carefully weighed before implementing any behavior
  272.         described with this label.
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Droms                       Standards Track                     [Page 5]
  283.  
  284. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  285.  
  286.  
  287.       o "MAY"
  288.  
  289.         This word or the adjective "OPTIONAL" means that this item is
  290.         truly optional.  One vendor may choose to include the item
  291.         because a particular marketplace requires it or because it
  292.         enhances the product, for example; another vendor may omit the
  293.         same item.
  294.  
  295. 1.5 Terminology
  296.  
  297.    This document uses the following terms:
  298.  
  299.       o "DHCP client"
  300.  
  301.       A DHCP client is an Internet host using DHCP to obtain
  302.       configuration parameters such as a network address.
  303.  
  304.       o "DHCP server"
  305.  
  306.       A DHCP server is an Internet host that returns configuration
  307.       parameters to DHCP clients.
  308.  
  309.       o "BOOTP relay agent"
  310.  
  311.       A BOOTP relay agent or relay agent is an Internet host or router
  312.       that passes DHCP messages between DHCP clients and DHCP servers.
  313.       DHCP is designed to use the same relay agent behavior as specified
  314.       in the BOOTP protocol specification.
  315.  
  316.       o "binding"
  317.  
  318.       A binding is a collection of configuration parameters, including
  319.       at least an IP address, associated with or "bound to" a DHCP
  320.       client.  Bindings are managed by DHCP servers.
  321.  
  322. 1.6 Design goals
  323.  
  324.    The following list gives general design goals for DHCP.
  325.  
  326.       o DHCP should be a mechanism rather than a policy.  DHCP must
  327.         allow local system administrators control over configuration
  328.         parameters where desired; e.g., local system administrators
  329.         should be able to enforce local policies concerning allocation
  330.         and access to local resources where desired.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Droms                       Standards Track                     [Page 6]
  339.  
  340. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  341.  
  342.  
  343.       o Clients should require no manual configuration.  Each client
  344.         should be able to discover appropriate local configuration
  345.         parameters without user intervention and incorporate those
  346.         parameters into its own configuration.
  347.  
  348.       o Networks should require no manual configuration for individual
  349.         clients.  Under normal circumstances, the network manager
  350.         should not have to enter any per-client configuration
  351.         parameters.
  352.  
  353.       o DHCP should not require a server on each subnet.  To allow for
  354.         scale and economy, DHCP must work across routers or through the
  355.         intervention of BOOTP relay agents.
  356.  
  357.       o A DHCP client must be prepared to receive multiple responses
  358.         to a request for configuration parameters.  Some installations
  359.         may include multiple, overlapping DHCP servers to enhance
  360.         reliability and increase performance.
  361.  
  362.       o DHCP must coexist with statically configured, non-participating
  363.         hosts and with existing network protocol implementations.
  364.  
  365.       o DHCP must interoperate with the BOOTP relay agent behavior as
  366.         described by RFC 951 and by RFC 1542 [21].
  367.  
  368.       o DHCP must provide service to existing BOOTP clients.
  369.  
  370.    The following list gives design goals specific to the transmission of
  371.    the network layer parameters.  DHCP must:
  372.  
  373.       o Guarantee that any specific network address will not be in
  374.         use by more than one DHCP client at a time,
  375.  
  376.       o Retain DHCP client configuration across DHCP client reboot.  A
  377.         DHCP client should, whenever possible, be assigned the same
  378.         configuration parameters (e.g., network address) in response
  379.         to each request,
  380.  
  381.       o Retain DHCP client configuration across server reboots, and,
  382.         whenever possible, a DHCP client should be assigned the same
  383.         configuration parameters despite restarts of the DHCP mechanism,
  384.  
  385.       o Allow automated assignment of configuration parameters to new
  386.         clients to avoid hand configuration for new clients,
  387.  
  388.       o Support fixed or permanent allocation of configuration
  389.         parameters to specific clients.
  390.  
  391.  
  392.  
  393.  
  394. Droms                       Standards Track                     [Page 7]
  395.  
  396. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  397.  
  398.  
  399. 2. Protocol Summary
  400.  
  401.    From the client's point of view, DHCP is an extension of the BOOTP
  402.    mechanism.  This behavior allows existing BOOTP clients to
  403.    interoperate with DHCP servers without requiring any change to the
  404.    clients' initialization software.  RFC 1542 [2] details the
  405.    interactions between BOOTP and DHCP clients and servers [9].  There
  406.    are some new, optional transactions that optimize the interaction
  407.    between DHCP clients and servers that are described in sections 3 and
  408.    4.
  409.  
  410.    Figure 1 gives the format of a DHCP message and table 1 describes
  411.    each of the fields in the DHCP message.  The numbers in parentheses
  412.    indicate the size of each field in octets.  The names for the fields
  413.    given in the figure will be used throughout this document to refer to
  414.    the fields in DHCP messages.
  415.  
  416.    There are two primary differences between DHCP and BOOTP.  First,
  417.    DHCP defines mechanisms through which clients can be assigned a
  418.    network address for a finite lease, allowing for serial reassignment
  419.    of network addresses to different clients.  Second, DHCP provides the
  420.    mechanism for a client to acquire all of the IP configuration
  421.    parameters that it needs in order to operate.
  422.  
  423.    DHCP introduces a small change in terminology intended to clarify the
  424.    meaning of one of the fields.  What was the "vendor extensions" field
  425.    in BOOTP has been re-named the "options" field in DHCP. Similarly,
  426.    the tagged data items that were used inside the BOOTP "vendor
  427.    extensions" field, which were formerly referred to as "vendor
  428.    extensions," are now termed simply "options."
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Droms                       Standards Track                     [Page 8]
  451.  
  452. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  453.  
  454.  
  455.    0                   1                   2                   3
  456.    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
  457.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  458.    |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
  459.    +---------------+---------------+---------------+---------------+
  460.    |                            xid (4)                            |
  461.    +-------------------------------+-------------------------------+
  462.    |           secs (2)            |           flags (2)           |
  463.    +-------------------------------+-------------------------------+
  464.    |                          ciaddr  (4)                          |
  465.    +---------------------------------------------------------------+
  466.    |                          yiaddr  (4)                          |
  467.    +---------------------------------------------------------------+
  468.    |                          siaddr  (4)                          |
  469.    +---------------------------------------------------------------+
  470.    |                          giaddr  (4)                          |
  471.    +---------------------------------------------------------------+
  472.    |                                                               |
  473.    |                          chaddr  (16)                         |
  474.    |                                                               |
  475.    |                                                               |
  476.    +---------------------------------------------------------------+
  477.    |                                                               |
  478.    |                          sname   (64)                         |
  479.    +---------------------------------------------------------------+
  480.    |                                                               |
  481.    |                          file    (128)                        |
  482.    +---------------------------------------------------------------+
  483.    |                                                               |
  484.    |                          options (variable)                   |
  485.    +---------------------------------------------------------------+
  486.  
  487.                   Figure 1:  Format of a DHCP message
  488.  
  489.    DHCP defines a new 'client identifier' option that is used to pass an
  490.    explicit client identifier to a DHCP server.  This change eliminates
  491.    the overloading of the 'chaddr' field in BOOTP messages, where
  492.    'chaddr' is used both as a hardware address for transmission of BOOTP
  493.    reply messages and as a client identifier.  The 'client identifier'
  494.    is an opaque key, not to be interpreted by the server; for example,
  495.    the 'client identifier' may contain a hardware address, identical to
  496.    the contents of the 'chaddr' field, or it may contain another type of
  497.    identifier, such as a DNS name.  The 'client identifier' chosen by a
  498.    DHCP client MUST be unique to that client within the subnet to which
  499.    the client is attached. If the client uses a 'client identifier' in
  500.    one message, it MUST use that same identifier in all subsequent
  501.    messages, to ensure that all servers correctly identify the client.
  502.  
  503.  
  504.  
  505.  
  506. Droms                       Standards Track                     [Page 9]
  507.  
  508. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  509.  
  510.  
  511.    DHCP clarifies the interpretation of the 'siaddr' field as the
  512.    address of the server to use in the next step of the client's
  513.    bootstrap process.  A DHCP server may return its own address in the
  514.    'siaddr' field, if the server is prepared to supply the next
  515.    bootstrap service (e.g., delivery of an operating system executable
  516.    image).  A DHCP server always returns its own address in the 'server
  517.    identifier' option.
  518.  
  519.    FIELD      OCTETS       DESCRIPTION
  520.    -----      ------       -----------
  521.  
  522.    op            1  Message op code / message type.
  523.                     1 = BOOTREQUEST, 2 = BOOTREPLY
  524.    htype         1  Hardware address type, see ARP section in "Assigned
  525.                     Numbers" RFC; e.g., '1' = 10mb ethernet.
  526.    hlen          1  Hardware address length (e.g.  '6' for 10mb
  527.                     ethernet).
  528.    hops          1  Client sets to zero, optionally used by relay agents
  529.                     when booting via a relay agent.
  530.    xid           4  Transaction ID, a random number chosen by the
  531.                     client, used by the client and server to associate
  532.                     messages and responses between a client and a
  533.                     server.
  534.    secs          2  Filled in by client, seconds elapsed since client
  535.                     began address acquisition or renewal process.
  536.    flags         2  Flags (see figure 2).
  537.    ciaddr        4  Client IP address; only filled in if client is in
  538.                     BOUND, RENEW or REBINDING state and can respond
  539.                     to ARP requests.
  540.    yiaddr        4  'your' (client) IP address.
  541.    siaddr        4  IP address of next server to use in bootstrap;
  542.                     returned in DHCPOFFER, DHCPACK by server.
  543.    giaddr        4  Relay agent IP address, used in booting via a
  544.                     relay agent.
  545.    chaddr       16  Client hardware address.
  546.    sname        64  Optional server host name, null terminated string.
  547.    file        128  Boot file name, null terminated string; "generic"
  548.                     name or null in DHCPDISCOVER, fully qualified
  549.                     directory-path name in DHCPOFFER.
  550.    options     var  Optional parameters field.  See the options
  551.                     documents for a list of defined options.
  552.  
  553.            Table 1:  Description of fields in a DHCP message
  554.  
  555.    The 'options' field is now variable length. A DHCP client must be
  556.    prepared to receive DHCP messages with an 'options' field of at least
  557.    length 312 octets.  This requirement implies that a DHCP client must
  558.    be prepared to receive a message of up to 576 octets, the minimum IP
  559.  
  560.  
  561.  
  562. Droms                       Standards Track                    [Page 10]
  563.  
  564. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  565.  
  566.  
  567.    datagram size an IP host must be prepared to accept [3].  DHCP
  568.    clients may negotiate the use of larger DHCP messages through the
  569.    'maximum DHCP message size' option.  The options field may be further
  570.    extended into the 'file' and 'sname' fields.
  571.  
  572.    In the case of a client using DHCP for initial configuration (before
  573.    the client's TCP/IP software has been completely configured), DHCP
  574.    requires creative use of the client's TCP/IP software and liberal
  575.    interpretation of RFC 1122.  The TCP/IP software SHOULD accept and
  576.    forward to the IP layer any IP packets delivered to the client's
  577.    hardware address before the IP address is configured; DHCP servers
  578.    and BOOTP relay agents may not be able to deliver DHCP messages to
  579.    clients that cannot accept hardware unicast datagrams before the
  580.    TCP/IP software is configured.
  581.  
  582.    To work around some clients that cannot accept IP unicast datagrams
  583.    before the TCP/IP software is configured as discussed in the previous
  584.    paragraph, DHCP uses the 'flags' field [21].  The leftmost bit is
  585.    defined as the BROADCAST (B) flag.  The semantics of this flag are
  586.    discussed in section 4.1 of this document.  The remaining bits of the
  587.    flags field are reserved for future use.  They MUST be set to zero by
  588.    clients and ignored by servers and relay agents.  Figure 2 gives the
  589.    format of the 'flags' field.
  590.  
  591.                                     1 1 1 1 1 1
  592.                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  593.                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  594.                 |B|             MBZ             |
  595.                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  596.  
  597.                 B:  BROADCAST flag
  598.  
  599.                 MBZ:  MUST BE ZERO (reserved for future use)
  600.  
  601.                 Figure 2:  Format of the 'flags' field
  602.  
  603. 2.1 Configuration parameters repository
  604.  
  605.    The first service provided by DHCP is to provide persistent storage
  606.    of network parameters for network clients.  The model of DHCP
  607.    persistent storage is that the DHCP service stores a key-value entry
  608.    for each client, where the key is some unique identifier (for
  609.    example, an IP subnet number and a unique identifier within the
  610.    subnet) and the value contains the configuration parameters for the
  611.    client.
  612.  
  613.    For example, the key might be the pair (IP-subnet-number, hardware-
  614.    address) (note that the "hardware-address" should be typed by the
  615.  
  616.  
  617.  
  618. Droms                       Standards Track                    [Page 11]
  619.  
  620. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  621.  
  622.  
  623.    type of hardware to accommodate possible duplication of hardware
  624.    addresses resulting from bit-ordering problems in a mixed-media,
  625.    bridged network) allowing for serial or concurrent reuse of a
  626.    hardware address on different subnets, and for hardware addresses
  627.    that may not be globally unique.  Alternately, the key might be the
  628.    pair (IP-subnet-number, hostname), allowing the server to assign
  629.    parameters intelligently to a DHCP client that has been moved to a
  630.    different subnet or has changed hardware addresses (perhaps because
  631.    the network interface failed and was replaced). The protocol defines
  632.    that the key will be (IP-subnet-number, hardware-address) unless the
  633.    client explicitly supplies an identifier using the 'client
  634.    identifier' option.           A client can query the DHCP service to
  635.    retrieve its configuration parameters.  The client interface to the
  636.    configuration parameters repository consists of protocol messages to
  637.    request configuration parameters and responses from the server
  638.    carrying the configuration parameters.
  639.  
  640. 2.2 Dynamic allocation of network addresses
  641.  
  642.    The second service provided by DHCP is the allocation of temporary or
  643.    permanent network (IP) addresses to clients.  The basic mechanism for
  644.    the dynamic allocation of network addresses is simple: a client
  645.    requests the use of an address for some period of time.  The
  646.    allocation mechanism (the collection of DHCP servers) guarantees not
  647.    to reallocate that address within the requested time and attempts to
  648.    return the same network address each time the client requests an
  649.    address.  In this document, the period over which a network address
  650.    is allocated to a client is referred to as a "lease" [11].  The
  651.    client may extend its lease with subsequent requests.  The client may
  652.    issue a message to release the address back to the server when the
  653.    client no longer needs the address.  The client may ask for a
  654.    permanent assignment by asking for an infinite lease.  Even when
  655.    assigning "permanent" addresses, a server may choose to give out
  656.    lengthy but non-infinite leases to allow detection of the fact that
  657.    the client has been retired.
  658.  
  659.    In some environments it will be necessary to reassign network
  660.    addresses due to exhaustion of available addresses.  In such
  661.    environments, the allocation mechanism will reuse addresses whose
  662.    lease has expired.  The server should use whatever information is
  663.    available in the configuration information repository to choose an
  664.    address to reuse.  For example, the server may choose the least
  665.    recently assigned address.  As a consistency check, the allocating
  666.    server SHOULD probe the reused address before allocating the address,
  667.    e.g., with an ICMP echo request, and the client SHOULD probe the
  668.    newly received address, e.g., with ARP.
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Droms                       Standards Track                    [Page 12]
  675.  
  676. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  677.  
  678.  
  679. 3. The Client-Server Protocol
  680.  
  681.    DHCP uses the BOOTP message format defined in RFC 951 and given in
  682.    table 1 and figure 1.  The 'op' field of each DHCP message sent from
  683.    a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
  684.    'op' field of each DHCP message sent from a server to a client.
  685.  
  686.    The first four octets of the 'options' field of the DHCP message
  687.    contain the (decimal) values 99, 130, 83 and 99, respectively (this
  688.    is the same magic cookie as is defined in RFC 1497 [17]).  The
  689.    remainder of the 'options' field consists of a list of tagged
  690.    parameters that are called "options".  All of the "vendor extensions"
  691.    listed in RFC 1497 are also DHCP options.  RFC 1533 gives the
  692.    complete set of options defined for use with DHCP.
  693.  
  694.    Several options have been defined so far.  One particular option -
  695.    the "DHCP message type" option - must be included in every DHCP
  696.    message.  This option defines the "type" of the DHCP message.
  697.    Additional options may be allowed, required, or not allowed,
  698.    depending on the DHCP message type.
  699.  
  700.    Throughout this document, DHCP messages that include a 'DHCP message
  701.    type' option will be referred to by the type of the message; e.g., a
  702.    DHCP message with 'DHCP message type' option type 1 will be referred
  703.    to as a "DHCPDISCOVER" message.
  704.  
  705. 3.1 Client-server interaction - allocating a network address
  706.  
  707.    The following summary of the protocol exchanges between clients and
  708.    servers refers to the DHCP messages described in table 2.  The
  709.    timeline diagram in figure 3 shows the timing relationships in a
  710.    typical client-server interaction.  If the client already knows its
  711.    address, some steps may be omitted; this abbreviated interaction is
  712.    described in section 3.2.
  713.  
  714.    1. The client broadcasts a DHCPDISCOVER message on its local physical
  715.       subnet.  The DHCPDISCOVER message MAY include options that suggest
  716.       values for the network address and lease duration.  BOOTP relay
  717.       agents may pass the message on to DHCP servers not on the same
  718.       physical subnet.
  719.  
  720.    2. Each server may respond with a DHCPOFFER message that includes an
  721.       available network address in the 'yiaddr' field (and other
  722.       configuration parameters in DHCP options).  Servers need not
  723.       reserve the offered network address, although the protocol will
  724.       work more efficiently if the server avoids allocating the offered
  725.       network address to another client.  When allocating a new address,
  726.       servers SHOULD check that the offered network address is not
  727.  
  728.  
  729.  
  730. Droms                       Standards Track                    [Page 13]
  731.  
  732. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  733.  
  734.  
  735.       already in use; e.g., the server may probe the offered address
  736.       with an ICMP Echo Request.  Servers SHOULD be implemented so that
  737.       network administrators MAY choose to disable probes of newly
  738.       allocated addresses.  The server transmits the DHCPOFFER message
  739.       to the client, using the BOOTP relay agent if necessary.
  740.  
  741.    Message         Use
  742.    -------         ---
  743.  
  744.    DHCPDISCOVER -  Client broadcast to locate available servers.
  745.  
  746.    DHCPOFFER    -  Server to client in response to DHCPDISCOVER with
  747.                    offer of configuration parameters.
  748.  
  749.    DHCPREQUEST  -  Client message to servers either (a) requesting
  750.                    offered parameters from one server and implicitly
  751.                    declining offers from all others, (b) confirming
  752.                    correctness of previously allocated address after,
  753.                    e.g., system reboot, or (c) extending the lease on a
  754.                    particular network address.
  755.  
  756.    DHCPACK      -  Server to client with configuration parameters,
  757.                    including committed network address.
  758.  
  759.    DHCPNAK      -  Server to client indicating client's notion of network
  760.                    address is incorrect (e.g., client has moved to new
  761.                    subnet) or client's lease as expired
  762.  
  763.    DHCPDECLINE  -  Client to server indicating network address is already
  764.                    in use.
  765.  
  766.    DHCPRELEASE  -  Client to server relinquishing network address and
  767.                    cancelling remaining lease.
  768.  
  769.    DHCPINFORM   -  Client to server, asking only for local configuration
  770.                    parameters; client already has externally configured
  771.                    network address.
  772.  
  773.                           Table 2:  DHCP messages
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Droms                       Standards Track                    [Page 14]
  787.  
  788. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  789.  
  790.  
  791.                 Server          Client          Server
  792.             (not selected)                    (selected)
  793.  
  794.                   v               v               v
  795.                   |               |               |
  796.                   |     Begins initialization     |
  797.                   |               |               |
  798.                   | _____________/|\____________  |
  799.                   |/DHCPDISCOVER | DHCPDISCOVER  \|
  800.                   |               |               |
  801.               Determines          |          Determines
  802.              configuration        |         configuration
  803.                   |               |               |
  804.                   |\             |  ____________/ |
  805.                   | \________    | /DHCPOFFER     |
  806.                   | DHCPOFFER\   |/               |
  807.                   |           \  |                |
  808.                   |       Collects replies        |
  809.                   |             \|                |
  810.                   |     Selects configuration     |
  811.                   |               |               |
  812.                   | _____________/|\____________  |
  813.                   |/ DHCPREQUEST  |  DHCPREQUEST\ |
  814.                   |               |               |
  815.                   |               |     Commits configuration
  816.                   |               |               |
  817.                   |               | _____________/|
  818.                   |               |/ DHCPACK      |
  819.                   |               |               |
  820.                   |    Initialization complete    |
  821.                   |               |               |
  822.                   .               .               .
  823.                   .               .               .
  824.                   |               |               |
  825.                   |      Graceful shutdown        |
  826.                   |               |               |
  827.                   |               |\ ____________ |
  828.                   |               | DHCPRELEASE  \|
  829.                   |               |               |
  830.                   |               |        Discards lease
  831.                   |               |               |
  832.                   v               v               v
  833.      Figure 3: Timeline diagram of messages exchanged between DHCP
  834.                client and servers when allocating a new network address
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Droms                       Standards Track                    [Page 15]
  843.  
  844. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  845.  
  846.  
  847.   3. The client receives one or more DHCPOFFER messages from one or more
  848.      servers.  The client may choose to wait for multiple responses.
  849.      The client chooses one server from which to request configuration
  850.      parameters, based on the configuration parameters offered in the
  851.      DHCPOFFER messages.  The client broadcasts a DHCPREQUEST message
  852.      that MUST include the 'server identifier' option to indicate which
  853.      server it has selected, and that MAY include other options
  854.      specifying desired configuration values.  The 'requested IP
  855.      address' option MUST be set to the value of 'yiaddr' in the
  856.      DHCPOFFER message from the server.  This DHCPREQUEST message is
  857.      broadcast and relayed through DHCP/BOOTP relay agents.  To help
  858.      ensure that any BOOTP relay agents forward the DHCPREQUEST message
  859.      to the same set of DHCP servers that received the original
  860.      DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
  861.      value in the DHCP message header's 'secs' field and be sent to the
  862.      same IP broadcast address as the original DHCPDISCOVER message.
  863.      The client times out and retransmits the DHCPDISCOVER message if
  864.      the client receives no DHCPOFFER messages.
  865.  
  866.   4. The servers receive the DHCPREQUEST broadcast from the client.
  867.      Those servers not selected by the DHCPREQUEST message use the
  868.      message as notification that the client has declined that server's
  869.      offer.  The server selected in the DHCPREQUEST message commits the
  870.      binding for the client to persistent storage and responds with a
  871.      DHCPACK message containing the configuration parameters for the
  872.      requesting client.  The combination of 'client identifier' or
  873.      'chaddr' and assigned network address constitute a unique
  874.      identifier for the client's lease and are used by both the client
  875.      and server to identify a lease referred to in any DHCP messages.
  876.      Any configuration parameters in the DHCPACK message SHOULD NOT
  877.      conflict with those in the earlier DHCPOFFER message to which the
  878.      client is responding.  The server SHOULD NOT check the offered
  879.      network address at this point. The 'yiaddr' field in the DHCPACK
  880.      messages is filled in with the selected network address.
  881.  
  882.      If the selected server is unable to satisfy the DHCPREQUEST message
  883.      (e.g., the requested network address has been allocated), the
  884.      server SHOULD respond with a DHCPNAK message.
  885.  
  886.      A server MAY choose to mark addresses offered to clients in
  887.      DHCPOFFER messages as unavailable.  The server SHOULD mark an
  888.      address offered to a client in a DHCPOFFER message as available if
  889.      the server receives no DHCPREQUEST message from that client.
  890.  
  891.   5. The client receives the DHCPACK message with configuration
  892.      parameters.  The client SHOULD perform a final check on the
  893.      parameters (e.g., ARP for allocated network address), and notes the
  894.      duration of the lease specified in the DHCPACK message.  At this
  895.  
  896.  
  897.  
  898. Droms                       Standards Track                    [Page 16]
  899.  
  900. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  901.  
  902.  
  903.      point, the client is configured.  If the client detects that the
  904.      address is already in use (e.g., through the use of ARP), the
  905.      client MUST send a DHCPDECLINE message to the server and restarts
  906.      the configuration process.  The client SHOULD wait a minimum of ten
  907.      seconds before restarting the configuration process to avoid
  908.      excessive network traffic in case of looping.
  909.  
  910.      If the client receives a DHCPNAK message, the client restarts the
  911.      configuration process.
  912.  
  913.      The client times out and retransmits the DHCPREQUEST message if the
  914.      client receives neither a DHCPACK or a DHCPNAK message.  The client
  915.      retransmits the DHCPREQUEST according to the retransmission
  916.      algorithm in section 4.1.  The client should choose to retransmit
  917.      the DHCPREQUEST enough times to give adequate probability of
  918.      contacting the server without causing the client (and the user of
  919.      that client) to wait overly long before giving up; e.g., a client
  920.      retransmitting as described in section 4.1 might retransmit the
  921.      DHCPREQUEST message four times, for a total delay of 60 seconds,
  922.      before restarting the initialization procedure.  If the client
  923.      receives neither a DHCPACK or a DHCPNAK message after employing the
  924.      retransmission algorithm, the client reverts to INIT state and
  925.      restarts the initialization process.  The client SHOULD notify the
  926.      user that the initialization process has failed and is restarting.
  927.  
  928.   6. The client may choose to relinquish its lease on a network address
  929.      by sending a DHCPRELEASE message to the server.  The client
  930.      identifies the lease to be released with its 'client identifier',
  931.      or 'chaddr' and network address in the DHCPRELEASE message. If the
  932.      client used a 'client identifier' when it obtained the lease, it
  933.      MUST use the same 'client identifier' in the DHCPRELEASE message.
  934.  
  935. 3.2 Client-server interaction - reusing a previously allocated network
  936.     address
  937.  
  938.    If a client remembers and wishes to reuse a previously allocated
  939.    network address, a client may choose to omit some of the steps
  940.    described in the previous section.  The timeline diagram in figure 4
  941.    shows the timing relationships in a typical client-server interaction
  942.    for a client reusing a previously allocated network address.
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Droms                       Standards Track                    [Page 17]
  955.  
  956. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  957.  
  958.  
  959.    1. The client broadcasts a DHCPREQUEST message on its local subnet.
  960.       The message includes the client's network address in the
  961.       'requested IP address' option. As the client has not received its
  962.       network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
  963.       relay agents pass the message on to DHCP servers not on the same
  964.       subnet.  If the client used a 'client identifier' to obtain its
  965.       address, the client MUST use the same 'client identifier' in the
  966.       DHCPREQUEST message.
  967.  
  968.    2. Servers with knowledge of the client's configuration parameters
  969.       respond with a DHCPACK message to the client.  Servers SHOULD NOT
  970.       check that the client's network address is already in use; the
  971.       client may respond to ICMP Echo Request messages at this point.
  972.  
  973.                 Server          Client          Server
  974.  
  975.                   v               v               v
  976.                   |                |               |
  977.                   |              Begins            |
  978.                   |          initialization        |
  979.                   |                |               |
  980.                   |                /|\             |
  981.                   |   _________ __/ | \__________  |
  982.                   | /DHCPREQU EST  |  DHCPREQUEST\ |
  983.                   |/               |              \|
  984.                   |                |               |
  985.                Locates             |            Locates
  986.             configuration          |         configuration
  987.                   |                |               |
  988.                   |\               |              /|
  989.                   | \              |  ___________/ |
  990.                   |  \             | /  DHCPACK    |
  991.                   |   \ _______    |/              |
  992.                   |     DHCPACK\   |               |
  993.                   |          Initialization        |
  994.                   |             complete           |
  995.                   |               \|               |
  996.                   |                |               |
  997.                   |           (Subsequent          |
  998.                   |             DHCPACKS           |
  999.                   |             ignored)           |
  1000.                   |                |               |
  1001.                   |                |               |
  1002.                   v                v               v
  1003.  
  1004.      Figure 4: Timeline diagram of messages exchanged between DHCP
  1005.                client and servers when reusing a previously allocated
  1006.                network address
  1007.  
  1008.  
  1009.  
  1010. Droms                       Standards Track                    [Page 18]
  1011.  
  1012. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1013.  
  1014.  
  1015.       If the client's request is invalid (e.g., the client has moved
  1016.       to a new subnet), servers SHOULD respond with a DHCPNAK message to
  1017.       the client. Servers SHOULD NOT respond if their information is not
  1018.       guaranteed to be accurate.  For example, a server that identifies a
  1019.       request for an expired binding that is owned by another server SHOULD
  1020.       NOT respond with a DHCPNAK unless the servers are using an explicit
  1021.       mechanism to maintain coherency among the servers.
  1022.  
  1023.       If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
  1024.       the same subnet as the server.  The server MUST
  1025.       broadcast the DHCPNAK message to the 0xffffffff broadcast address
  1026.       because the client may not have a correct network address or subnet
  1027.       mask, and the client may not be answering ARP requests.
  1028.       Otherwise, the server MUST send the DHCPNAK message to the IP
  1029.       address of the BOOTP relay agent, as recorded in 'giaddr'.  The
  1030.       relay agent will, in turn, forward the message directly to the
  1031.       client's hardware address, so that the DHCPNAK can be delivered even
  1032.       if the client has moved to a new network.
  1033.  
  1034.    3. The client receives the DHCPACK message with configuration
  1035.       parameters.  The client performs a final check on the parameters
  1036.       (as in section 3.1), and notes the duration of the lease specified
  1037.       in the DHCPACK message.  The specific lease is implicitly identified
  1038.       by the 'client identifier' or 'chaddr' and the network address.  At
  1039.       this point, the client is configured.
  1040.  
  1041.       If the client detects that the IP address in the DHCPACK message
  1042.       is already in use, the client MUST send a DHCPDECLINE message to the
  1043.       server and restarts the configuration process by requesting a
  1044.       new network address.  This action corresponds to the client
  1045.       moving to the INIT state in the DHCP state diagram, which is
  1046.       described in section 4.4.
  1047.  
  1048.       If the client receives a DHCPNAK message, it cannot reuse its
  1049.       remembered network address.  It must instead request a new
  1050.       address by restarting the configuration process, this time
  1051.       using the (non-abbreviated) procedure described in section
  1052.       3.1.  This action also corresponds to the client moving to
  1053.       the INIT state in the DHCP state diagram.
  1054.  
  1055.       The client times out and retransmits the DHCPREQUEST message if
  1056.       the client receives neither a DHCPACK nor a DHCPNAK message.  The
  1057.       client retransmits the DHCPREQUEST according to the retransmission
  1058.       algorithm in section 4.1.  The client should choose to retransmit
  1059.       the DHCPREQUEST enough times to give adequate probability of
  1060.       contacting the server without causing the client (and the user of
  1061.       that client) to wait overly long before giving up; e.g., a client
  1062.       retransmitting as described in section 4.1 might retransmit the
  1063.  
  1064.  
  1065.  
  1066. Droms                       Standards Track                    [Page 19]
  1067.  
  1068. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1069.  
  1070.  
  1071.       DHCPREQUEST message four times, for a total delay of 60 seconds,
  1072.       before restarting the initialization procedure.  If the client
  1073.       receives neither a DHCPACK or a DHCPNAK message after employing
  1074.       the retransmission algorithm, the client MAY choose to use the
  1075.       previously allocated network address and configuration parameters
  1076.       for the remainder of the unexpired lease.  This corresponds to
  1077.       moving to BOUND state in the client state transition diagram shown
  1078.       in figure 5.
  1079.  
  1080.    4. The client may choose to relinquish its lease on a network
  1081.       address by sending a DHCPRELEASE message to the server.  The
  1082.       client identifies the lease to be released with its
  1083.       'client identifier', or 'chaddr' and network address in the
  1084.       DHCPRELEASE message.
  1085.  
  1086.       Note that in this case, where the client retains its network
  1087.       address locally, the client will not normally relinquish its
  1088.       lease during a graceful shutdown.  Only in the case where the
  1089.       client explicitly needs to relinquish its lease, e.g., the client
  1090.       is about to be moved to a different subnet, will the client send
  1091.       a DHCPRELEASE message.
  1092.  
  1093. 3.3 Interpretation and representation of time values
  1094.  
  1095.    A client acquires a lease for a network address for a fixed period of
  1096.    time (which may be infinite).  Throughout the protocol, times are to
  1097.    be represented in units of seconds.  The time value of 0xffffffff is
  1098.    reserved to represent "infinity".
  1099.  
  1100.    As clients and servers may not have synchronized clocks, times are
  1101.    represented in DHCP messages as relative times, to be interpreted
  1102.    with respect to the client's local clock.  Representing relative
  1103.    times in units of seconds in an unsigned 32 bit word gives a range of
  1104.    relative times from 0 to approximately 100 years, which is sufficient
  1105.    for the relative times to be measured using DHCP.
  1106.  
  1107.    The algorithm for lease duration interpretation given in the previous
  1108.    paragraph assumes that client and server clocks are stable relative
  1109.    to each other.  If there is drift between the two clocks, the server
  1110.    may consider the lease expired before the client does.  To
  1111.    compensate, the server may return a shorter lease duration to the
  1112.    client than the server commits to its local database of client
  1113.    information.
  1114.  
  1115. 3.4 Obtaining parameters with externally configured network address
  1116.  
  1117.    If a client has obtained a network address through some other means
  1118.    (e.g., manual configuration), it may use a DHCPINFORM request message
  1119.  
  1120.  
  1121.  
  1122. Droms                       Standards Track                    [Page 20]
  1123.  
  1124. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1125.  
  1126.  
  1127.    to obtain other local configuration parameters.  Servers receiving a
  1128.    DHCPINFORM message construct a DHCPACK message with any local
  1129.    configuration parameters appropriate for the client without:
  1130.    allocating a new address, checking for an existing binding, filling
  1131.    in 'yiaddr' or including lease time parameters.  The servers SHOULD
  1132.    unicast the DHCPACK reply to the address given in the 'ciaddr' field
  1133.    of the DHCPINFORM message.
  1134.  
  1135.    The server SHOULD check the network address in a DHCPINFORM message
  1136.    for consistency, but MUST NOT check for an existing lease.  The
  1137.    server forms a DHCPACK message containing the configuration
  1138.    parameters for the requesting client and sends the DHCPACK message
  1139.    directly to the client.
  1140.  
  1141. 3.5 Client parameters in DHCP
  1142.  
  1143.    Not all clients require initialization of all parameters listed in
  1144.    Appendix A.  Two techniques are used to reduce the number of
  1145.    parameters transmitted from the server to the client.  First, most of
  1146.    the parameters have defaults defined in the Host Requirements RFCs;
  1147.    if the client receives no parameters from the server that override
  1148.    the defaults, a client uses those default values.  Second, in its
  1149.    initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
  1150.    server with a list of specific parameters the client is interested
  1151.    in.  If the client includes a list of parameters in a DHCPDISCOVER
  1152.    message, it MUST include that list in any subsequent DHCPREQUEST
  1153.    messages.
  1154.  
  1155.    The client SHOULD include the 'maximum DHCP message size' option to
  1156.    let the server know how large the server may make its DHCP messages.
  1157.    The parameters returned to a client may still exceed the space
  1158.    allocated to options in a DHCP message.  In this case, two additional
  1159.    options flags (which must appear in the 'options' field of the
  1160.    message) indicate that the 'file' and 'sname' fields are to be used
  1161.    for options.
  1162.  
  1163.    The client can inform the server which configuration parameters the
  1164.    client is interested in by including the 'parameter request list'
  1165.    option.  The data portion of this option explicitly lists the options
  1166.    requested by tag number.
  1167.  
  1168.    In addition, the client may suggest values for the network address
  1169.    and lease time in the DHCPDISCOVER message.  The client may include
  1170.    the 'requested IP address' option to suggest that a particular IP
  1171.    address be assigned, and may include the 'IP address lease time'
  1172.    option to suggest the lease time it would like.  Other options
  1173.    representing "hints" at configuration parameters are allowed in a
  1174.    DHCPDISCOVER or DHCPREQUEST message.  However, additional options may
  1175.  
  1176.  
  1177.  
  1178. Droms                       Standards Track                    [Page 21]
  1179.  
  1180. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1181.  
  1182.  
  1183.    be ignored by servers, and multiple servers may, therefore, not
  1184.    return identical values for some options.  The 'requested IP address'
  1185.    option is to be filled in only in a DHCPREQUEST message when the
  1186.    client is verifying network parameters obtained previously. The
  1187.    client fills in the 'ciaddr' field only when correctly configured
  1188.    with an IP address in BOUND, RENEWING or REBINDING state.
  1189.  
  1190.    If a server receives a DHCPREQUEST message with an invalid 'requested
  1191.    IP address', the server SHOULD respond to the client with a DHCPNAK
  1192.    message and may choose to report the problem to the system
  1193.    administrator.  The server may include an error message in the
  1194.    'message' option.
  1195.  
  1196. 3.6 Use of DHCP in clients with multiple interfaces
  1197.  
  1198.    A client with multiple network interfaces must use DHCP through each
  1199.    interface independently to obtain configuration information
  1200.    parameters for those separate interfaces.
  1201.  
  1202. 3.7 When clients should use DHCP
  1203.  
  1204.    A client SHOULD use DHCP to reacquire or verify its IP address and
  1205.    network parameters whenever the local network parameters may have
  1206.    changed; e.g., at system boot time or after a disconnection from the
  1207.    local network, as the local network configuration may change without
  1208.    the client's or user's knowledge.
  1209.  
  1210.    If a client has knowledge of a previous network address and is unable
  1211.    to contact a local DHCP server, the client may continue to use the
  1212.    previous network address until the lease for that address expires.
  1213.    If the lease expires before the client can contact a DHCP server, the
  1214.    client must immediately discontinue use of the previous network
  1215.    address and may inform local users of the problem.
  1216.  
  1217. 4. Specification of the DHCP client-server protocol
  1218.  
  1219.    In this section, we assume that a DHCP server has a block of network
  1220.    addresses from which it can satisfy requests for new addresses.  Each
  1221.    server also maintains a database of allocated addresses and leases in
  1222.    local permanent storage.
  1223.  
  1224. 4.1 Constructing and sending DHCP messages
  1225.  
  1226.    DHCP clients and servers both construct DHCP messages by filling in
  1227.    fields in the fixed format section of the message and appending
  1228.    tagged data items in the variable length option area.  The options
  1229.    area includes first a four-octet 'magic cookie' (which was described
  1230.    in section 3), followed by the options.  The last option must always
  1231.  
  1232.  
  1233.  
  1234. Droms                       Standards Track                    [Page 22]
  1235.  
  1236. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1237.  
  1238.  
  1239.    be the 'end' option.
  1240.  
  1241.    DHCP uses UDP as its transport protocol.  DHCP messages from a client
  1242.    to a server are sent to the 'DHCP server' port (67), and DHCP
  1243.    messages from a server to a client are sent to the 'DHCP client' port
  1244.    (68). A server with multiple network address (e.g., a multi-homed
  1245.    host) MAY use any of its network addresses in outgoing DHCP messages.
  1246.  
  1247.    The 'server identifier' field is used both to identify a DHCP server
  1248.    in a DHCP message and as a destination address from clients to
  1249.    servers.  A server with multiple network addresses MUST be prepared
  1250.    to to accept any of its network addresses as identifying that server
  1251.    in a DHCP message.  To accommodate potentially incomplete network
  1252.    connectivity, a server MUST choose an address as a 'server
  1253.    identifier' that, to the best of the server's knowledge, is reachable
  1254.    from the client.  For example, if the DHCP server and the DHCP client
  1255.    are connected to the same subnet (i.e., the 'giaddr' field in the
  1256.    message from the client is zero), the server SHOULD select the IP
  1257.    address the server is using for communication on that subnet as the
  1258.    'server identifier'.  If the server is using multiple IP addresses on
  1259.    that subnet, any such address may be used.  If the server has
  1260.    received a message through a DHCP relay agent, the server SHOULD
  1261.    choose an address from the interface on which the message was
  1262.    recieved as the 'server identifier' (unless the server has other,
  1263.    better information on which to make its choice).  DHCP clients MUST
  1264.    use the IP address provided in the 'server identifier' option for any
  1265.    unicast requests to the DHCP server.
  1266.  
  1267.    DHCP messages broadcast by a client prior to that client obtaining
  1268.    its IP address must have the source address field in the IP header
  1269.    set to 0.
  1270.  
  1271.    If the 'giaddr' field in a DHCP message from a client is non-zero,
  1272.    the server sends any return messages to the 'DHCP server' port on the
  1273.    BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
  1274.    field is zero and the 'ciaddr' field is nonzero, then the server
  1275.    unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
  1276.    If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
  1277.    set, then the server broadcasts DHCPOFFER and DHCPACK messages to
  1278.    0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
  1279.    'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
  1280.    messages to the client's hardware address and 'yiaddr' address.  In
  1281.    all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
  1282.    messages to 0xffffffff.
  1283.  
  1284.    If the options in a DHCP message extend into the 'sname' and 'file'
  1285.    fields, the 'option overload' option MUST appear in the 'options'
  1286.    field, with value 1, 2 or 3, as specified in RFC 1533.  If the
  1287.  
  1288.  
  1289.  
  1290. Droms                       Standards Track                    [Page 23]
  1291.  
  1292. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1293.  
  1294.  
  1295.    'option overload' option is present in the 'options' field, the
  1296.    options in the 'options' field MUST be terminated by an 'end' option,
  1297.    and MAY contain one or more 'pad' options to fill the options field.
  1298.    The options in the 'sname' and 'file' fields (if in use as indicated
  1299.    by the 'options overload' option) MUST begin with the first octet of
  1300.    the field, MUST be terminated by an 'end' option, and MUST be
  1301.    followed by 'pad' options to fill the remainder of the field.  Any
  1302.    individual option in the 'options', 'sname' and 'file' fields MUST be
  1303.    entirely contained in that field.  The options in the 'options' field
  1304.    MUST be interpreted first, so that any 'option overload' options may
  1305.    be interpreted.  The 'file' field MUST be interpreted next (if the
  1306.    'option overload' option indicates that the 'file' field contains
  1307.    DHCP options), followed by the 'sname' field.
  1308.  
  1309.    The values to be passed in an 'option' tag may be too long to fit in
  1310.    the 255 octets available to a single option (e.g., a list of routers
  1311.    in a 'router' option [21]).  Options may appear only once, unless
  1312.    otherwise specified in the options document.  The client concatenates
  1313.    the values of multiple instances of the same option into a single
  1314.    parameter list for configuration.
  1315.  
  1316.    DHCP clients are responsible for all message retransmission.  The
  1317.    client MUST adopt a retransmission strategy that incorporates a
  1318.    randomized exponential backoff algorithm to determine the delay
  1319.    between retransmissions.  The delay between retransmissions SHOULD be
  1320.    chosen to allow sufficient time for replies from the server to be
  1321.    delivered based on the characteristics of the internetwork between
  1322.    the client and the server.  For example, in a 10Mb/sec Ethernet
  1323.    internetwork, the delay before the first retransmission SHOULD be 4
  1324.    seconds randomized by the value of a uniform random number chosen
  1325.    from the range -1 to +1.  Clients with clocks that provide resolution
  1326.    granularity of less than one second may choose a non-integer
  1327.    randomization value.  The delay before the next retransmission SHOULD
  1328.    be 8 seconds randomized by the value of a uniform number chosen from
  1329.    the range -1 to +1.  The retransmission delay SHOULD be doubled with
  1330.    subsequent retransmissions up to a maximum of 64 seconds.  The client
  1331.    MAY provide an indication of retransmission attempts to the user as
  1332.    an indication of the progress of the configuration process.
  1333.  
  1334.    The 'xid' field is used by the client to match incoming DHCP messages
  1335.    with pending requests.  A DHCP client MUST choose 'xid's in such a
  1336.    way as to minimize the chance of using an 'xid' identical to one used
  1337.    by another client. For example, a client may choose a different,
  1338.    random initial 'xid' each time the client is rebooted, and
  1339.    subsequently use sequential 'xid's until the next reboot.  Selecting
  1340.    a new 'xid' for each retransmission is an implementation decision.  A
  1341.    client may choose to reuse the same 'xid' or select a new 'xid' for
  1342.    each retransmitted message.
  1343.  
  1344.  
  1345.  
  1346. Droms                       Standards Track                    [Page 24]
  1347.  
  1348. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1349.  
  1350.  
  1351.    Normally, DHCP servers and BOOTP relay agents attempt to deliver
  1352.    DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
  1353.    uicast delivery.  The IP destination address (in the IP header) is
  1354.    set to the DHCP 'yiaddr' address and the link-layer destination
  1355.    address is set to the DHCP 'chaddr' address.  Unfortunately, some
  1356.    client implementations are unable to receive such unicast IP
  1357.    datagrams until the implementation has been configured with a valid
  1358.    IP address (leading to a deadlock in which the client's IP address
  1359.    cannot be delivered until the client has been configured with an IP
  1360.    address).
  1361.  
  1362.    A client that cannot receive unicast IP datagrams until its protocol
  1363.    software has been configured with an IP address SHOULD set the
  1364.    BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
  1365.    DHCPREQUEST messages that client sends.  The BROADCAST bit will
  1366.    provide a hint to the DHCP server and BOOTP relay agent to broadcast
  1367.    any messages to the client on the client's subnet.  A client that can
  1368.    receive unicast IP datagrams before its protocol software has been
  1369.    configured SHOULD clear the BROADCAST bit to 0.  The BOOTP
  1370.    clarifications document discusses the ramifications of the use of the
  1371.    BROADCAST bit [21].
  1372.  
  1373.    A server or relay agent sending or relaying a DHCP message directly
  1374.    to a DHCP client (i.e., not to a relay agent specified in the
  1375.    'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
  1376.    field.  If this bit is set to 1, the DHCP message SHOULD be sent as
  1377.    an IP broadcast using an IP broadcast address (preferably 0xffffffff)
  1378.    as the IP destination address and the link-layer broadcast address as
  1379.    the link-layer destination address.  If the BROADCAST bit is cleared
  1380.    to 0, the message SHOULD be sent as an IP unicast to the IP address
  1381.    specified in the 'yiaddr' field and the link-layer address specified
  1382.    in the 'chaddr' field.  If unicasting is not possible, the message
  1383.    MAY be sent as an IP broadcast using an IP broadcast address
  1384.    (preferably 0xffffffff) as the IP destination address and the link-
  1385.    layer broadcast address as the link-layer destination address.
  1386.  
  1387. 4.2 DHCP server administrative controls
  1388.  
  1389.    DHCP servers are not required to respond to every DHCPDISCOVER and
  1390.    DHCPREQUEST message they receive.  For example, a network
  1391.    administrator, to retain stringent control over the clients attached
  1392.    to the network, may choose to configure DHCP servers to respond only
  1393.    to clients that have been previously registered through some external
  1394.    mechanism.  The DHCP specification describes only the interactions
  1395.    between clients and servers when the clients and servers choose to
  1396.    interact; it is beyond the scope of the DHCP specification to
  1397.    describe all of the administrative controls that system
  1398.    administrators might want to use.  Specific DHCP server
  1399.  
  1400.  
  1401.  
  1402. Droms                       Standards Track                    [Page 25]
  1403.  
  1404. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1405.  
  1406.  
  1407.    implementations may incorporate any controls or policies desired by a
  1408.    network administrator.
  1409.  
  1410.    In some environments, a DHCP server will have to consider the values
  1411.    of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
  1412.    messages when determining the correct parameters for a particular
  1413.    client.
  1414.  
  1415.    A DHCP server needs to use some unique identifier to associate a
  1416.    client with its lease.  The client MAY choose to explicitly provide
  1417.    the identifier through the 'client identifier' option.  If the client
  1418.    supplies a 'client identifier', the client MUST use the same 'client
  1419.    identifier' in all subsequent messages, and the server MUST use that
  1420.    identifier to identify the client.  If the client does not provide a
  1421.    'client identifier' option, the server MUST use the contents of the
  1422.    'chaddr' field to identify the client. It is crucial for a DHCP
  1423.    client to use an identifier unique within the subnet to which the
  1424.    client is attached in the 'client identifier' option.  Use of
  1425.    'chaddr' as the client's unique identifier may cause unexpected
  1426.    results, as that identifier may be associated with a hardware
  1427.    interface that could be moved to a new client.  Some sites may choose
  1428.    to use a manufacturer's serial number as the 'client identifier', to
  1429.    avoid unexpected changes in a clients network address due to transfer
  1430.    of hardware interfaces among computers.  Sites may also choose to use
  1431.    a DNS name as the 'client identifier', causing address leases to be
  1432.    associated with the DNS name rather than a specific hardware box.
  1433.  
  1434.    DHCP clients are free to use any strategy in selecting a DHCP server
  1435.    among those from which the client receives a DHCPOFFER message.  The
  1436.    client implementation of DHCP SHOULD provide a mechanism for the user
  1437.    to select directly the 'vendor class identifier' values.
  1438.  
  1439. 4.3 DHCP server behavior
  1440.  
  1441.    A DHCP server processes incoming DHCP messages from a client based on
  1442.    the current state of the binding for that client.  A DHCP server can
  1443.    receive the following messages from a client:
  1444.  
  1445.       o DHCPDISCOVER
  1446.  
  1447.       o DHCPREQUEST
  1448.  
  1449.       o DHCPDECLINE
  1450.  
  1451.       o DHCPRELEASE
  1452.  
  1453.       o DHCPINFORM
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Droms                       Standards Track                    [Page 26]
  1459.  
  1460. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1461.  
  1462.  
  1463.    Table 3 gives the use of the fields and options in a DHCP message by
  1464.    a server.  The remainder of this section describes the action of the
  1465.    DHCP server for each possible incoming message.
  1466.  
  1467. 4.3.1 DHCPDISCOVER message
  1468.  
  1469.    When a server receives a DHCPDISCOVER message from a client, the
  1470.    server chooses a network address for the requesting client.  If no
  1471.    address is available, the server may choose to report the problem to
  1472.    the system administrator. If an address is available, the new address
  1473.    SHOULD be chosen as follows:
  1474.  
  1475.       o The client's current address as recorded in the client's current
  1476.         binding, ELSE
  1477.  
  1478.       o The client's previous address as recorded in the client's (now
  1479.         expired or released) binding, if that address is in the server's
  1480.         pool of available addresses and not already allocated, ELSE
  1481.  
  1482.       o The address requested in the 'Requested IP Address' option, if that
  1483.         address is valid and not already allocated, ELSE
  1484.  
  1485.       o A new address allocated from the server's pool of available
  1486.         addresses; the address is selected based on the subnet from which
  1487.         the message was received (if 'giaddr' is 0) or on the address of
  1488.         the relay agent that forwarded the message ('giaddr' when not 0).
  1489.  
  1490.    As described in section 4.2, a server MAY, for administrative
  1491.    reasons, assign an address other than the one requested, or may
  1492.    refuse to allocate an address to a particular client even though free
  1493.    addresses are available.
  1494.  
  1495.    Note that, in some network architectures (e.g., internets with more
  1496.    than one IP subnet assigned to a physical network segment), it may be
  1497.    the case that the DHCP client should be assigned an address from a
  1498.    different subnet than the address recorded in 'giaddr'.  Thus, DHCP
  1499.    does not require that the client be assigned as address from the
  1500.    subnet in 'giaddr'.  A server is free to choose some other subnet,
  1501.    and it is beyond the scope of the DHCP specification to describe ways
  1502.    in which the assigned IP address might be chosen.
  1503.  
  1504.    While not required for correct operation of DHCP, the server SHOULD
  1505.    NOT reuse the selected network address before the client responds to
  1506.    the server's DHCPOFFER message.  The server may choose to record the
  1507.    address as offered to the client.
  1508.  
  1509.    The server must also choose an expiration time for the lease, as
  1510.    follows:
  1511.  
  1512.  
  1513.  
  1514. Droms                       Standards Track                    [Page 27]
  1515.  
  1516. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1517.  
  1518.  
  1519.    o IF the client has not requested a specific lease in the
  1520.      DHCPDISCOVER message and the client already has an assigned network
  1521.      address, the server returns the lease expiration time previously
  1522.      assigned to that address (note that the client must explicitly
  1523.      request a specific lease to extend the expiration time on a
  1524.      previously assigned address), ELSE
  1525.  
  1526.    o IF the client has not requested a specific lease in the
  1527.      DHCPDISCOVER message and the client does not have an assigned
  1528.      network address, the server assigns a locally configured default
  1529.      lease time, ELSE
  1530.  
  1531.    o IF the client has requested a specific lease in the DHCPDISCOVER
  1532.      message (regardless of whether the client has an assigned network
  1533.      address), the server may choose either to return the requested
  1534.      lease (if the lease is acceptable to local policy) or select
  1535.      another lease.
  1536.  
  1537. Field      DHCPOFFER            DHCPACK             DHCPNAK
  1538. -----      ---------            -------             -------
  1539. 'op'       BOOTREPLY            BOOTREPLY           BOOTREPLY
  1540. 'htype'    (From "Assigned Numbers" RFC)
  1541. 'hlen'     (Hardware address length in octets)
  1542. 'hops'     0                    0                   0
  1543. 'xid'      'xid' from client    'xid' from client   'xid' from client
  1544.            DHCPDISCOVER         DHCPREQUEST         DHCPREQUEST
  1545.            message              message             message
  1546. 'secs'     0                    0                   0
  1547. 'ciaddr'   0                    'ciaddr' from       0
  1548.                                 DHCPREQUEST or 0
  1549. 'yiaddr'   IP address offered   IP address          0
  1550.            to client            assigned to client
  1551. 'siaddr'   IP address of next   IP address of next  0
  1552.            bootstrap server     bootstrap server
  1553. 'flags'    'flags' from         'flags' from        'flags' from
  1554.            client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
  1555.            message              message             message
  1556. 'giaddr'   'giaddr' from        'giaddr' from       'giaddr' from
  1557.            client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
  1558.            message              message             message
  1559. 'chaddr'   'chaddr' from        'chaddr' from       'chaddr' from
  1560.            client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
  1561.            message              message             message
  1562. 'sname'    Server host name     Server host name    (unused)
  1563.            or options           or options
  1564. 'file'     Client boot file     Client boot file    (unused)
  1565.            name or options      name or options
  1566. 'options'  options              options
  1567.  
  1568.  
  1569.  
  1570. Droms                       Standards Track                    [Page 28]
  1571.  
  1572. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1573.  
  1574.  
  1575. Option                    DHCPOFFER    DHCPACK            DHCPNAK
  1576. ------                    ---------    -------            -------
  1577. Requested IP address      MUST NOT     MUST NOT           MUST NOT
  1578. IP address lease time     MUST         MUST (DHCPREQUEST) MUST NOT
  1579.                                        MUST NOT (DHCPINFORM)
  1580. Use 'file'/'sname' fields MAY          MAY                MUST NOT
  1581. DHCP message type         DHCPOFFER    DHCPACK            DHCPNAK
  1582. Parameter request list    MUST NOT     MUST NOT           MUST NOT
  1583. Message                   SHOULD       SHOULD             SHOULD
  1584. Client identifier         MUST NOT     MUST NOT           MAY
  1585. Vendor class identifier   MAY          MAY                MAY
  1586. Server identifier         MUST         MUST               MUST
  1587. Maximum message size      MUST NOT     MUST NOT           MUST NOT
  1588. All others                MAY          MAY                MUST NOT
  1589.  
  1590.            Table 3:  Fields and options used by DHCP servers
  1591.  
  1592.    Once the network address and lease have been determined, the server
  1593.    constructs a DHCPOFFER message with the offered configuration
  1594.    parameters.  It is important for all DHCP servers to return the same
  1595.    parameters (with the possible exception of a newly allocated network
  1596.    address) to ensure predictable client behavior regardless of which
  1597.    server the client selects.  The configuration parameters MUST be
  1598.    selected by applying the following rules in the order given below.
  1599.    The network administrator is responsible for configuring multiple
  1600.    DHCP servers to ensure uniform responses from those servers.  The
  1601.    server MUST return to the client:
  1602.  
  1603.    o The client's network address, as determined by the rules given
  1604.      earlier in this section,
  1605.  
  1606.    o The expiration time for the client's lease, as determined by the
  1607.      rules given earlier in this section,
  1608.  
  1609.    o Parameters requested by the client, according to the following
  1610.      rules:
  1611.  
  1612.         -- IF the server has been explicitly configured with a default
  1613.            value for the parameter, the server MUST include that value
  1614.            in an appropriate option in the 'option' field, ELSE
  1615.  
  1616.         -- IF the server recognizes the parameter as a parameter
  1617.            defined in the Host Requirements Document, the server MUST
  1618.            include the default value for that parameter as given in the
  1619.            Host Requirements Document in an appropriate option in the
  1620.            'option' field, ELSE
  1621.  
  1622.         -- The server MUST NOT return a value for that parameter,
  1623.  
  1624.  
  1625.  
  1626. Droms                       Standards Track                    [Page 29]
  1627.  
  1628. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1629.  
  1630.  
  1631.      The server MUST supply as many of the requested parameters as
  1632.      possible and MUST omit any parameters it cannot provide.  The
  1633.      server MUST include each requested parameter only once unless
  1634.      explicitly allowed in the DHCP Options and BOOTP Vendor
  1635.      Extensions document.
  1636.  
  1637.    o Any parameters from the existing binding that differ from the Host
  1638.      Requirements Document defaults,
  1639.  
  1640.    o Any parameters specific to this client (as identified by
  1641.      the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
  1642.      or DHCPREQUEST message), e.g., as configured by the network
  1643.      administrator,
  1644.  
  1645.    o Any parameters specific to this client's class (as identified
  1646.      by the contents of the 'vendor class identifier'
  1647.      option in the DHCPDISCOVER or DHCPREQUEST message),
  1648.      e.g., as configured by the network administrator; the parameters
  1649.      MUST be identified by an exact match between the client's vendor
  1650.      class identifiers and the client's classes identified in the
  1651.      server,
  1652.  
  1653.    o Parameters with non-default values on the client's subnet.
  1654.  
  1655.    The server MAY choose to return the 'vendor class identifier' used to
  1656.    determine the parameters in the DHCPOFFER message to assist the
  1657.    client in selecting which DHCPOFFER to accept.  The server inserts
  1658.    the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
  1659.    the DHCPOFFER message and sends the DHCPOFFER message to the
  1660.    requesting client.
  1661.  
  1662. 4.3.2 DHCPREQUEST message
  1663.  
  1664.    A DHCPREQUEST message may come from a client responding to a
  1665.    DHCPOFFER message from a server, from a client verifying a previously
  1666.    allocated IP address or from a client extending the lease on a
  1667.    network address.  If the DHCPREQUEST message contains a 'server
  1668.    identifier' option, the message is in response to a DHCPOFFER
  1669.    message.  Otherwise, the message is a request to verify or extend an
  1670.    existing lease.  If the client uses a 'client identifier' in a
  1671.    DHCPREQUEST message, it MUST use that same 'client identifier' in all
  1672.    subsequent messages. If the client included a list of requested
  1673.    parameters in a DHCPDISCOVER message, it MUST include that list in
  1674.    all subsequent messages.
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Droms                       Standards Track                    [Page 30]
  1683.  
  1684. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1685.  
  1686.  
  1687.    Any configuration parameters in the DHCPACK message SHOULD NOT
  1688.    conflict with those in the earlier DHCPOFFER message to which the
  1689.    client is responding.  The client SHOULD use the parameters in the
  1690.    DHCPACK message for configuration.
  1691.  
  1692.    Clients send DHCPREQUEST messages as follows:
  1693.  
  1694.    o DHCPREQUEST generated during SELECTING state:
  1695.  
  1696.       Client inserts the address of the selected server in 'server
  1697.       identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
  1698.       filled in with the yiaddr value from the chosen DHCPOFFER.
  1699.  
  1700.       Note that the client may choose to collect several DHCPOFFER
  1701.       messages and select the "best" offer.  The client indicates its
  1702.       selection by identifying the offering server in the DHCPREQUEST
  1703.       message.  If the client receives no acceptable offers, the client
  1704.       may choose to try another DHCPDISCOVER message.  Therefore, the
  1705.       servers may not receive a specific DHCPREQUEST from which they can
  1706.       decide whether or not the client has accepted the offer.  Because
  1707.       the servers have not committed any network address assignments on
  1708.       the basis of a DHCPOFFER, servers are free to reuse offered
  1709.       network addresses in response to subsequent requests.  As an
  1710.       implementation detail, servers SHOULD NOT reuse offered addresses
  1711.       and may use an implementation-specific timeout mechanism to decide
  1712.       when to reuse an offered address.
  1713.  
  1714.    o DHCPREQUEST generated during INIT-REBOOT state:
  1715.  
  1716.       'server identifier' MUST NOT be filled in, 'requested IP address'
  1717.       option MUST be filled in with client's notion of its previously
  1718.       assigned address. 'ciaddr' MUST be zero. The client is seeking to
  1719.       verify a previously allocated, cached configuration. Server SHOULD
  1720.       send a DHCPNAK message to the client if the 'requested IP address'
  1721.       is incorrect, or is on the wrong network.
  1722.  
  1723.       Determining whether a client in the INIT-REBOOT state is on the
  1724.       correct network is done by examining the contents of 'giaddr', the
  1725.       'requested IP address' option, and a database lookup. If the DHCP
  1726.       server detects that the client is on the wrong net (i.e., the
  1727.       result of applying the local subnet mask or remote subnet mask (if
  1728.       'giaddr' is not zero) to 'requested IP address' option value
  1729.       doesn't match reality), then the server SHOULD send a DHCPNAK
  1730.       message to the client.
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Droms                       Standards Track                    [Page 31]
  1739.  
  1740. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1741.  
  1742.  
  1743.       If the network is correct, then the DHCP server should check if
  1744.       the client's notion of its IP address is correct. If not, then the
  1745.       server SHOULD send a DHCPNAK message to the client. If the DHCP
  1746.       server has no record of this client, then it MUST remain silent,
  1747.       and MAY output a warning to the network administrator. This
  1748.       behavior is necessary for peaceful coexistence of non-
  1749.       communicating DHCP servers on the same wire.
  1750.  
  1751.       If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
  1752.       the same subnet as the server.  The server MUST broadcast the
  1753.       DHCPNAK message to the 0xffffffff broadcast address because the
  1754.       client may not have a correct network address or subnet mask, and
  1755.       the client may not be answering ARP requests.
  1756.  
  1757.       If 'giaddr' is set in the DHCPREQUEST message, the client is on a
  1758.       different subnet.  The server MUST set the broadcast bit in the
  1759.       DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
  1760.       client, because the client may not have a correct network address
  1761.       or subnet mask, and the client may not be answering ARP requests.
  1762.  
  1763.    o DHCPREQUEST generated during RENEWING state:
  1764.  
  1765.       'server identifier' MUST NOT be filled in, 'requested IP address'
  1766.       option MUST NOT be filled in, 'ciaddr' MUST be filled in with
  1767.       client's IP address. In this situation, the client is completely
  1768.       configured, and is trying to extend its lease. This message will
  1769.       be unicast, so no relay agents will be involved in its
  1770.       transmission.  Because 'giaddr' is therefore not filled in, the
  1771.       DHCP server will trust the value in 'ciaddr', and use it when
  1772.       replying to the client.
  1773.  
  1774.       A client MAY choose to renew or extend its lease prior to T1.  The
  1775.       server may choose not to extend the lease (as a policy decision by
  1776.       the network administrator), but should return a DHCPACK message
  1777.       regardless.
  1778.  
  1779.    o DHCPREQUEST generated during REBINDING state:
  1780.  
  1781.       'server identifier' MUST NOT be filled in, 'requested IP address'
  1782.       option MUST NOT be filled in, 'ciaddr' MUST be filled in with
  1783.       client's IP address. In this situation, the client is completely
  1784.       configured, and is trying to extend its lease. This message MUST
  1785.       be broadcast to the 0xffffffff IP broadcast address.  The DHCP
  1786.       server SHOULD check 'ciaddr' for correctness before replying to
  1787.       the DHCPREQUEST.
  1788.  
  1789.  
  1790.  
  1791.  
  1792.  
  1793.  
  1794. Droms                       Standards Track                    [Page 32]
  1795.  
  1796. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1797.  
  1798.  
  1799.       The DHCPREQUEST from a REBINDING client is intended to accommodate
  1800.       sites that have multiple DHCP servers and a mechanism for
  1801.       maintaining consistency among leases managed by multiple servers.
  1802.       A DHCP server MAY extend a client's lease only if it has local
  1803.       administrative authority to do so.
  1804.  
  1805. 4.3.3 DHCPDECLINE message
  1806.  
  1807.    If the server receives a DHCPDECLINE message, the client has
  1808.    discovered through some other means that the suggested network
  1809.    address is already in use.  The server MUST mark the network address
  1810.    as not available and SHOULD notify the local system administrator of
  1811.    a possible configuration problem.
  1812.  
  1813. 4.3.4 DHCPRELEASE message
  1814.  
  1815.    Upon receipt of a DHCPRELEASE message, the server marks the network
  1816.    address as not allocated.  The server SHOULD retain a record of the
  1817.    client's initialization parameters for possible reuse in response to
  1818.    subsequent requests from the client.
  1819.  
  1820. 4.3.5 DHCPINFORM message
  1821.  
  1822.    The server responds to a DHCPINFORM message by sending a DHCPACK
  1823.    message directly to the address given in the 'ciaddr' field of the
  1824.    DHCPINFORM message.  The server MUST NOT send a lease expiration time
  1825.    to the client and SHOULD NOT fill in 'yiaddr'.  The server includes
  1826.    other parameters in the DHCPACK message as defined in section 4.3.1.
  1827.  
  1828. 4.3.6 Client messages
  1829.  
  1830.    Table 4 details the differences between messages from clients in
  1831.    various states.
  1832.  
  1833.    ---------------------------------------------------------------------
  1834.    |              |INIT-REBOOT  |SELECTING    |RENEWING     |REBINDING |
  1835.    ---------------------------------------------------------------------
  1836.    |broad/unicast |broadcast    |broadcast    |unicast      |broadcast |
  1837.    |server-ip     |MUST NOT     |MUST         |MUST NOT     |MUST NOT  |
  1838.    |requested-ip  |MUST         |MUST         |MUST NOT     |MUST NOT  |
  1839.    |ciaddr        |zero         |zero         |IP address   |IP address|
  1840.    ---------------------------------------------------------------------
  1841.  
  1842.               Table 4: Client messages from different states
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Droms                       Standards Track                    [Page 33]
  1851.  
  1852. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1853.  
  1854.  
  1855. 4.4 DHCP client behavior
  1856.  
  1857.    Figure 5 gives a state-transition diagram for a DHCP client.  A
  1858.    client can receive the following messages from a server:
  1859.  
  1860.          o DHCPOFFER
  1861.  
  1862.          o DHCPACK
  1863.  
  1864.          o DHCPNAK
  1865.  
  1866.    The DHCPINFORM message is not shown in figure 5.  A client simply
  1867.    sends the DHCPINFORM and waits for DHCPACK messages.  Once the client
  1868.    has selected its parameters, it has completed the configuration
  1869.    process.
  1870.  
  1871.    Table 5 gives the use of the fields and options in a DHCP message by
  1872.    a client.  The remainder of this section describes the action of the
  1873.    DHCP client for each possible incoming message.  The description in
  1874.    the following section corresponds to the full configuration procedure
  1875.    previously described in section 3.1, and the text in the subsequent
  1876.    section corresponds to the abbreviated configuration procedure
  1877.    described in section 3.2.
  1878.  
  1879.  
  1880.  
  1881.  
  1882.  
  1883.  
  1884.  
  1885.  
  1886.  
  1887.  
  1888.  
  1889.  
  1890.  
  1891.  
  1892.  
  1893.  
  1894.  
  1895.  
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906. Droms                       Standards Track                    [Page 34]
  1907.  
  1908. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1909.  
  1910.  
  1911.  --------                               -------
  1912. |        | +-------------------------->|       |<-------------------+
  1913. | INIT-  | |     +-------------------->| INIT  |                    |
  1914. | REBOOT |DHCPNAK/         +---------->|       |<---+               |
  1915. |        |Restart|         |            -------     |               |
  1916.  --------  |  DHCPNAK/     |               |                        |
  1917.     |      Discard offer   |      -/Send DHCPDISCOVER               |
  1918. -/Send DHCPREQUEST         |               |                        |
  1919.     |      |     |      DHCPACK            v        |               |
  1920.  -----------     |   (not accept.)/   -----------   |               |
  1921. |           |    |  Send DHCPDECLINE |           |                  |
  1922. | REBOOTING |    |         |         | SELECTING |<----+            |
  1923. |           |    |        /          |           |     |DHCPOFFER/  |
  1924.  -----------     |       /            -----------   |  |Collect     |
  1925.     |            |      /                  |   |       |  replies   |
  1926. DHCPACK/         |     /  +----------------+   +-------+            |
  1927. Record lease, set|    |   v   Select offer/                         |
  1928. timers T1, T2   ------------  send DHCPREQUEST      |               |
  1929.     |   +----->|            |             DHCPNAK, Lease expired/   |
  1930.     |   |      | REQUESTING |                  Halt network         |
  1931.     DHCPOFFER/ |            |                       |               |
  1932.     Discard     ------------                        |               |
  1933.     |   |        |        |                   -----------           |
  1934.     |   +--------+     DHCPACK/              |           |          |
  1935.     |              Record lease, set    -----| REBINDING |          |
  1936.     |                timers T1, T2     /     |           |          |
  1937.     |                     |        DHCPACK/   -----------           |
  1938.     |                     v     Record lease, set   ^               |
  1939.     +----------------> -------      /timers T1,T2   |               |
  1940.                +----->|       |<---+                |               |
  1941.                |      | BOUND |<---+                |               |
  1942.   DHCPOFFER, DHCPACK, |       |    |            T2 expires/   DHCPNAK/
  1943.    DHCPNAK/Discard     -------     |             Broadcast  Halt network
  1944.                |       | |         |            DHCPREQUEST         |
  1945.                +-------+ |        DHCPACK/          |               |
  1946.                     T1 expires/   Record lease, set |               |
  1947.                  Send DHCPREQUEST timers T1, T2     |               |
  1948.                  to leasing server |                |               |
  1949.                          |   ----------             |               |
  1950.                          |  |          |------------+               |
  1951.                          +->| RENEWING |                            |
  1952.                             |          |----------------------------+
  1953.                              ----------
  1954.           Figure 5:  State-transition diagram for DHCP clients
  1955.  
  1956.  
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Droms                       Standards Track                    [Page 35]
  1963.  
  1964. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  1965.  
  1966.  
  1967. 4.4.1 Initialization and allocation of network address
  1968.  
  1969.    The client begins in INIT state and forms a DHCPDISCOVER message.
  1970.    The client SHOULD wait a random time between one and ten seconds to
  1971.    desynchronize the use of DHCP at startup.  The client sets 'ciaddr'
  1972.    to 0x00000000.  The client MAY request specific parameters by
  1973.    including the 'parameter request list' option.  The client MAY
  1974.    suggest a network address and/or lease time by including the
  1975.    'requested IP address' and 'IP address lease time' options.  The
  1976.    client MUST include its hardware address in the 'chaddr' field, if
  1977.    necessary for delivery of DHCP reply messages.  The client MAY
  1978.    include a different unique identifier in the 'client identifier'
  1979.    option, as discussed in section 4.2.  If the client included a list
  1980.    of requested parameters in a DHCPDISCOVER message, it MUST include
  1981.    that list in all subsequent messages.
  1982.  
  1983.    The client generates and records a random transaction identifier and
  1984.    inserts that identifier into the 'xid' field.  The client records its
  1985.    own local time for later use in computing the lease expiration.  The
  1986.    client then broadcasts the DHCPDISCOVER on the local hardware
  1987.    broadcast address to the 0xffffffff IP broadcast address and 'DHCP
  1988.    server' UDP port.
  1989.  
  1990.    If the 'xid' of an arriving DHCPOFFER message does not match the
  1991.    'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
  1992.    must be silently discarded.  Any arriving DHCPACK messages must be
  1993.    silently discarded.
  1994.  
  1995.    The client collects DHCPOFFER messages over a period of time, selects
  1996.    one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
  1997.    messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
  1998.    from the previously used server) and extracts the server address from
  1999.    the 'server identifier' option in the DHCPOFFER message.  The time
  2000.    over which the client collects messages and the mechanism used to
  2001.    select one DHCPOFFER are implementation dependent.
  2002.  
  2003.  
  2004.  
  2005.  
  2006.  
  2007.  
  2008.  
  2009.  
  2010.  
  2011.  
  2012.  
  2013.  
  2014.  
  2015.  
  2016.  
  2017.  
  2018. Droms                       Standards Track                    [Page 36]
  2019.  
  2020. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  2021.  
  2022.  
  2023. Field      DHCPDISCOVER          DHCPREQUEST           DHCPDECLINE,
  2024.            DHCPINFORM                                  DHCPRELEASE
  2025. -----      ------------          -----------           -----------
  2026. 'op'       BOOTREQUEST           BOOTREQUEST           BOOTREQUEST
  2027. 'htype'    (From "Assigned Numbers" RFC)
  2028. 'hlen'     (Hardware address length in octets)
  2029. 'hops'     0                     0                     0
  2030. 'xid'      selected by client    'xid' from server     selected by
  2031.                                  DHCPOFFER message     client
  2032. 'secs'     0 or seconds since    0 or seconds since    0
  2033.            DHCP process started  DHCP process started
  2034. 'flags'    Set 'BROADCAST'       Set 'BROADCAST'       0
  2035.            flag if client        flag if client
  2036.            requires broadcast    requires broadcast
  2037.            reply                 reply
  2038. 'ciaddr'   0 (DHCPDISCOVER)      0 or client's         0 (DHCPDECLINE)
  2039.            client's              network address       client's network
  2040.            network address       (BOUND/RENEW/REBIND)  address
  2041.            (DHCPINFORM)                                (DHCPRELEASE)
  2042. 'yiaddr'   0                     0                     0
  2043. 'siaddr'   0                     0                     0
  2044. 'giaddr'   0                     0                     0
  2045. 'chaddr'   client's hardware     client's hardware     client's hardware
  2046.            address               address               address
  2047. 'sname'    options, if           options, if           (unused)
  2048.            indicated in          indicated in
  2049.            'sname/file'          'sname/file'
  2050.            option; otherwise     option; otherwise
  2051.            unused                unused
  2052. 'file'     options, if           options, if           (unused)
  2053.            indicated in          indicated in
  2054.            'sname/file'          'sname/file'
  2055.            option; otherwise     option; otherwise
  2056.            unused                unused
  2057. 'options'  options               options               (unused)
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065.  
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074. Droms                       Standards Track                    [Page 37]
  2075.  
  2076. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  2077.  
  2078.  
  2079. Option                     DHCPDISCOVER  DHCPREQUEST      DHCPDECLINE,
  2080.                            DHCPINFORM                     DHCPRELEASE
  2081. ------                     ------------  -----------      -----------
  2082. Requested IP address       MAY           MUST (in         MUST
  2083.                            (DISCOVER)    SELECTING or     (DHCPDECLINE),
  2084.                            MUST NOT      INIT-REBOOT)     MUST NOT
  2085.                            (INFORM)      MUST NOT (in     (DHCPRELEASE)
  2086.                                          BOUND or
  2087.                                          RENEWING)
  2088. IP address lease time      MAY           MAY              MUST NOT
  2089.                            (DISCOVER)
  2090.                            MUST NOT
  2091.                            (INFORM)
  2092. Use 'file'/'sname' fields  MAY           MAY              MAY
  2093. DHCP message type          DHCPDISCOVER/ DHCPREQUEST      DHCPDECLINE/
  2094.                            DHCPINFORM                     DHCPRELEASE
  2095. Client identifier          MAY           MAY              MAY
  2096. Vendor class identifier    MAY           MAY              MUST NOT
  2097. Server identifier          MUST NOT      MUST (after      MUST
  2098.                                          SELECTING)
  2099.                                          MUST NOT (after
  2100.                                          INIT-REBOOT,
  2101.                                          BOUND, RENEWING
  2102.                                          or REBINDING)
  2103. Parameter request list     MAY           MAY              MUST NOT
  2104. Maximum message size       MAY           MAY              MUST NOT
  2105. Message                    SHOULD NOT    SHOULD NOT       SHOULD
  2106. Site-specific              MAY           MAY              MUST NOT
  2107. All others                 MAY           MAY              MUST NOT
  2108.  
  2109.              Table 5:  Fields and options used by DHCP clients
  2110.  
  2111.    If the parameters are acceptable, the client records the address of
  2112.    the server that supplied the parameters from the 'server identifier'
  2113.    field and sends that address in the 'server identifier' field of a
  2114.    DHCPREQUEST broadcast message.  Once the DHCPACK message from the
  2115.    server arrives, the client is initialized and moves to BOUND state.
  2116.    The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
  2117.    message.  The client records the lease expiration time as the sum of
  2118.    the time at which the original request was sent and the duration of
  2119.    the lease from the DHCPACK message.    The client SHOULD perform a
  2120.    check on the suggested address to ensure that the address is not
  2121.    already in use.  For example, if the client is on a network that
  2122.    supports ARP, the client may issue an ARP request for the suggested
  2123.    request.  When broadcasting an ARP request for the suggested address,
  2124.    the client must fill in its own hardware address as the sender's
  2125.    hardware address, and 0 as the sender's IP address, to avoid
  2126.    confusing ARP caches in other hosts on the same subnet.  If the
  2127.  
  2128.  
  2129.  
  2130. Droms                       Standards Track                    [Page 38]
  2131.  
  2132. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  2133.  
  2134.  
  2135.    network address appears to be in use, the client MUST send a
  2136.    DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
  2137.    reply to announce the client's new IP address and clear any outdated
  2138.    ARP cache entries in hosts on the client's subnet.
  2139.  
  2140. 4.4.2 Initialization with known network address
  2141.  
  2142.    The client begins in INIT-REBOOT state and sends a DHCPREQUEST
  2143.    message.  The client MUST insert its known network address as a
  2144.    'requested IP address' option in the DHCPREQUEST message.  The client
  2145.    may request specific configuration parameters by including the
  2146.    'parameter request list' option.  The client generates and records a
  2147.    random transaction identifier and inserts that identifier into the
  2148.    'xid' field.  The client records its own local time for later use in
  2149.    computing the lease expiration.  The client MUST NOT include a
  2150.    'server identifier' in the DHCPREQUEST message.  The client then
  2151.    broadcasts the DHCPREQUEST on the local hardware broadcast address to
  2152.    the 'DHCP server' UDP port.
  2153.  
  2154.    Once a DHCPACK message with an 'xid' field matching that in the
  2155.    client's DHCPREQUEST message arrives from any server, the client is
  2156.    initialized and moves to BOUND state.  The client records the lease
  2157.    expiration time as the sum of the time at which the DHCPREQUEST
  2158.    message was sent and the duration of the lease from the DHCPACK
  2159.    message.
  2160.  
  2161. 4.4.3 Initialization with an externally assigned network address
  2162.  
  2163.    The client sends a DHCPINFORM message. The client may request
  2164.    specific configuration parameters by including the 'parameter request
  2165.    list' option. The client generates and records a random transaction
  2166.    identifier and inserts that identifier into the 'xid' field. The
  2167.    client places its own network address in the 'ciaddr' field. The
  2168.    client SHOULD NOT request lease time parameters.
  2169.  
  2170.    The client then unicasts the DHCPINFORM to the DHCP server if it
  2171.    knows the server's address, otherwise it broadcasts the message to
  2172.    the limited (all 1s) broadcast address.  DHCPINFORM messages MUST be
  2173.    directed to the 'DHCP server' UDP port.
  2174.  
  2175.    Once a DHCPACK message with an 'xid' field matching that in the
  2176.    client's DHCPINFORM message arrives from any server, the client is
  2177.    initialized.
  2178.  
  2179.    If the client does not receive a DHCPACK within a reasonable period
  2180.    of time (60 seconds or 4 tries if using timeout suggested in section
  2181.    4.1), then it SHOULD display a message informing the user of the
  2182.    problem, and then SHOULD begin network processing using suitable
  2183.  
  2184.  
  2185.  
  2186. Droms                       Standards Track                    [Page 39]
  2187.  
  2188. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  2189.  
  2190.  
  2191.    defaults as per Appendix A.
  2192.  
  2193. 4.4.4 Use of broadcast and unicast
  2194.  
  2195.    The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
  2196.    messages, unless the client knows the address of a DHCP server.  The
  2197.    client unicasts DHCPRELEASE messages to the server.  Because the
  2198.    client is declining the use of the IP address supplied by the server,
  2199.    the client broadcasts DHCPDECLINE messages.
  2200.  
  2201.    When the DHCP client knows the address of a DHCP server, in either
  2202.    INIT or REBOOTING state, the client may use that address in the
  2203.    DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
  2204.    The client may also use unicast to send DHCPINFORM messages to a
  2205.    known DHCP server.  If the client receives no response to DHCP
  2206.    messages sent to the IP address of a known DHCP server, the DHCP
  2207.    client reverts to using the IP broadcast address.
  2208.  
  2209. 4.4.5 Reacquisition and expiration
  2210.  
  2211.    The client maintains two times, T1 and T2, that specify the times at
  2212.    which the client tries to extend its lease on its network address.
  2213.    T1 is the time at which the client enters the RENEWING state and
  2214.    attempts to contact the server that originally issued the client's
  2215.    network address.  T2 is the time at which the client enters the
  2216.    REBINDING state and attempts to contact any server. T1 MUST be
  2217.    earlier than T2, which, in turn, MUST be earlier than the time at
  2218.    which the client's lease will expire.
  2219.  
  2220.    To avoid the need for synchronized clocks, T1 and T2 are expressed in
  2221.    options as relative times [2].
  2222.  
  2223.    At time T1 the client moves to RENEWING state and sends (via unicast)
  2224.    a DHCPREQUEST message to the server to extend its lease.  The client
  2225.    sets the 'ciaddr' field in the DHCPREQUEST to its current network
  2226.    address. The client records the local time at which the DHCPREQUEST
  2227.    message is sent for computation of the lease expiration time.  The
  2228.    client MUST NOT include a 'server identifier' in the DHCPREQUEST
  2229.    message.
  2230.  
  2231.    Any DHCPACK messages that arrive with an 'xid' that does not match
  2232.    the 'xid' of the client's DHCPREQUEST message are silently discarded.
  2233.    When the client receives a DHCPACK from the server, the client
  2234.    computes the lease expiration time as the sum of the time at which
  2235.    the client sent the DHCPREQUEST message and the duration of the lease
  2236.    in the DHCPACK message.  The client has successfully reacquired its
  2237.    network address, returns to BOUND state and may continue network
  2238.    processing.
  2239.  
  2240.  
  2241.  
  2242. Droms                       Standards Track                    [Page 40]
  2243.  
  2244. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  2245.  
  2246.  
  2247.    If no DHCPACK arrives before time T2, the client moves to REBINDING
  2248.    state and sends (via broadcast) a DHCPREQUEST message to extend its
  2249.    lease.  The client sets the 'ciaddr' field in the DHCPREQUEST to its
  2250.    current network address.  The client MUST NOT include a 'server
  2251.    identifier' in the DHCPREQUEST message.
  2252.  
  2253.    Times T1 and T2 are configurable by the server through options.  T1
  2254.    defaults to (0.5 * duration_of_lease).  T2 defaults to (0.875 *
  2255.    duration_of_lease).  Times T1 and T2 SHOULD be chosen with some
  2256.    random "fuzz" around a fixed value, to avoid synchronization of
  2257.    client reacquisition.
  2258.  
  2259.    A client MAY choose to renew or extend its lease prior to T1.  The
  2260.    server MAY choose to extend the client's lease according to policy
  2261.    set by the network administrator.  The server SHOULD return T1 and
  2262.    T2, and their values SHOULD be adjusted from their original values to
  2263.    take account of the time remaining on the lease.
  2264.  
  2265.    In both RENEWING and REBINDING states, if the client receives no
  2266.    response to its DHCPREQUEST message, the client SHOULD wait one-half
  2267.    of the remaining time until T2 (in RENEWING state) and one-half of
  2268.    the remaining lease time (in REBINDING state), down to a minimum of
  2269.    60 seconds, before retransmitting the DHCPREQUEST message.
  2270.  
  2271.    If the lease expires before the client receives a DHCPACK, the client
  2272.    moves to INIT state, MUST immediately stop any other network
  2273.    processing and requests network initialization parameters as if the
  2274.    client were uninitialized.  If the client then receives a DHCPACK
  2275.    allocating that client its previous network address, the client
  2276.    SHOULD continue network processing.  If the client is given a new
  2277.    network address, it MUST NOT continue using the previous network
  2278.    address and SHOULD notify the local users of the problem.
  2279.  
  2280. 4.4.6 DHCPRELEASE
  2281.  
  2282.    If the client no longer requires use of its assigned network address
  2283.    (e.g., the client is gracefully shut down), the client sends a
  2284.    DHCPRELEASE message to the server.  Note that the correct operation
  2285.    of DHCP does not depend on the transmission of DHCPRELEASE messages.
  2286.  
  2287.  
  2288.  
  2289.  
  2290.  
  2291.  
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298. Droms                       Standards Track                    [Page 41]
  2299.  
  2300. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  2301.  
  2302.  
  2303. 5. Acknowledgments
  2304.  
  2305.    The author thanks the many (and too numerous to mention!) members of
  2306.    the DHC WG for their tireless and ongoing efforts in the development
  2307.    of DHCP and this document.
  2308.  
  2309.    The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
  2310.    Mendonca in organizing DHCP interoperability testing sessions are
  2311.    gratefully acknowledged.
  2312.  
  2313.    The development of this document was supported in part by grants from
  2314.    the Corporation for National Research Initiatives (CNRI), Bucknell
  2315.    University and Sun Microsystems.
  2316.  
  2317. 6. References
  2318.  
  2319.    [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
  2320.        1983.
  2321.  
  2322.    [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
  2323.        Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
  2324.        University, October 1993.
  2325.  
  2326.    [3] Braden, R., Editor, "Requirements for Internet Hosts --
  2327.        Communication Layers", STD 3, RFC 1122, USC/Information Sciences
  2328.        Institute, October 1989.
  2329.  
  2330.    [4] Braden, R., Editor, "Requirements for Internet Hosts --
  2331.        Application and Support, STD 3, RFC 1123, USC/Information
  2332.        Sciences Institute, October 1989.
  2333.  
  2334.    [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
  2335.        (DRARP)", Work in Progress.
  2336.  
  2337.    [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
  2338.        Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
  2339.        Communications Review), 20(4):50--59, 1990.
  2340.  
  2341.    [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
  2342.        Stanford and SUN Microsystems, September 1985.
  2343.  
  2344.    [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
  2345.        PARC, September 1991.
  2346.  
  2347.    [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
  2348.        Bucknell University, October 1993.
  2349.  
  2350.  
  2351.  
  2352.  
  2353.  
  2354. Droms                       Standards Track                    [Page 42]
  2355.  
  2356. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  2357.  
  2358.  
  2359.    [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
  2360.         Address Resolution Protocol", RFC 903, Stanford, June 1984.
  2361.  
  2362.    [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
  2363.         Mechanism for Distributed File Cache Consistency", In Proc. of
  2364.         the Twelfth ACM Symposium on Operating Systems Design, 1989.
  2365.  
  2366.    [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
  2367.         13, RFC 1034, USC/Information Sciences Institute, November 1987.
  2368.  
  2369.    [13] Mockapetris, P., "Domain Names -- Implementation and
  2370.         Specification", STD 13, RFC 1035, USC/Information Sciences
  2371.         Institute, November 1987.
  2372.  
  2373.    [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
  2374.         November 1990.
  2375.  
  2376.    [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
  2377.         Hosts", Work in Progress.
  2378.  
  2379.    [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
  2380.         USC/Information Sciences Institute, September 1981.
  2381.  
  2382.    [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
  2383.         USC/Information Sciences Institute, August 1993.
  2384.  
  2385.    [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  2386.         USC/Information Sciences Institute, October 1994.
  2387.  
  2388.    [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
  2389.         Assignment of IP Addresses for use on an Ethernet. (Available
  2390.         from the Athena Project, MIT), 1989.
  2391.  
  2392.    [20] Sollins, K., "The TFTP Protocol (Revision 2)",  RFC 783, NIC,
  2393.         June 1981.
  2394.  
  2395.    [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
  2396.         Protocol", RFC 1542, Carnegie Mellon University, October 1993.
  2397.  
  2398. 7. Security Considerations
  2399.  
  2400.    DHCP is built directly on UDP and IP which are as yet inherently
  2401.    insecure.  Furthermore, DHCP is generally intended to make
  2402.    maintenance of remote and/or diskless hosts easier.  While perhaps
  2403.    not impossible, configuring such hosts with passwords or keys may be
  2404.    difficult and inconvenient.  Therefore, DHCP in its current form is
  2405.    quite insecure.
  2406.  
  2407.  
  2408.  
  2409.  
  2410. Droms                       Standards Track                    [Page 43]
  2411.  
  2412. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  2413.  
  2414.  
  2415.    Unauthorized DHCP servers may be easily set up.  Such servers can
  2416.    then send false and potentially disruptive information to clients
  2417.    such as incorrect or duplicate IP addresses, incorrect routing
  2418.    information (including spoof routers, etc.), incorrect domain
  2419.    nameserver addresses (such as spoof nameservers), and so on.
  2420.    Clearly, once this seed information is in place, an attacker can
  2421.    further compromise affected systems.
  2422.  
  2423.    Malicious DHCP clients could masquerade as legitimate clients and
  2424.    retrieve information intended for those legitimate clients.  Where
  2425.    dynamic allocation of resources is used, a malicious client could
  2426.    claim all resources for itself, thereby denying resources to
  2427.    legitimate clients.
  2428.  
  2429. 8. Author's Address
  2430.  
  2431.       Ralph Droms
  2432.       Computer Science Department
  2433.       323 Dana Engineering
  2434.       Bucknell University
  2435.       Lewisburg, PA 17837
  2436.  
  2437.       Phone: (717) 524-1145
  2438.       EMail: droms@bucknell.edu
  2439.  
  2440.  
  2441.  
  2442.  
  2443.  
  2444.  
  2445.  
  2446.  
  2447.  
  2448.  
  2449.  
  2450.  
  2451.  
  2452.  
  2453.  
  2454.  
  2455.  
  2456.  
  2457.  
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464.  
  2465.  
  2466. Droms                       Standards Track                    [Page 44]
  2467.  
  2468. RFC 2131          Dynamic Host Configuration Protocol         March 1997
  2469.  
  2470.  
  2471. A. Host Configuration Parameters
  2472.  
  2473.    IP-layer_parameters,_per_host:_
  2474.  
  2475.    Be a router                     on/off                 HRC 3.1
  2476.    Non-local source routing        on/off                 HRC 3.3.5
  2477.    Policy filters for
  2478.    non-local source routing        (list)                 HRC 3.3.5
  2479.    Maximum reassembly size         integer                HRC 3.3.2
  2480.    Default TTL                     integer                HRC 3.2.1.7
  2481.    PMTU aging timeout              integer                MTU 6.6
  2482.    MTU plateau table               (list)                 MTU 7
  2483.    IP-layer_parameters,_per_interface:_
  2484.    IP address                      (address)              HRC 3.3.1.6
  2485.    Subnet mask                     (address mask)         HRC 3.3.1.6
  2486.    MTU                             integer                HRC 3.3.3
  2487.    All-subnets-MTU                 on/off                 HRC 3.3.3
  2488.    Broadcast address flavor        0x00000000/0xffffffff  HRC 3.3.6
  2489.    Perform mask discovery          on/off                 HRC 3.2.2.9
  2490.    Be a mask supplier              on/off                 HRC 3.2.2.9
  2491.    Perform router discovery        on/off                 RD 5.1
  2492.    Router solicitation address     (address)              RD 5.1
  2493.    Default routers, list of:
  2494.            router address          (address)              HRC 3.3.1.6
  2495.            preference level        integer                HRC 3.3.1.6
  2496.    Static routes, list of:
  2497.            destination             (host/subnet/net)      HRC 3.3.1.2
  2498.            destination mask        (address mask)         HRC 3.3.1.2
  2499.            type-of-service         integer                HRC 3.3.1.2
  2500.            first-hop router        (address)              HRC 3.3.1.2
  2501.            ignore redirects        on/off                 HRC 3.3.1.2
  2502.            PMTU                    integer                MTU 6.6
  2503.            perform PMTU discovery  on/off                 MTU 6.6
  2504.  
  2505.    Link-layer_parameters,_per_interface:_
  2506.    Trailers                       on/off                 HRC 2.3.1
  2507.    ARP cache timeout              integer                HRC 2.3.2.1
  2508.    Ethernet encapsulation         (RFC 894/RFC 1042)     HRC 2.3.3
  2509.  
  2510.    TCP_parameters,_per_host:_
  2511.    TTL                            integer                HRC 4.2.2.19
  2512.    Keep-alive interval            integer                HRC 4.2.3.6
  2513.    Keep-alive data size           0/1                    HRC 4.2.3.6
  2514.  
  2515. Key:
  2516.  
  2517.    MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
  2518.    RD = Router Discovery (RFC 1256, Proposed Standard)
  2519.  
  2520.  
  2521.  
  2522. Droms                       Standards Track                    [Page 45]
  2523.  
  2524.