doc/rfc2131.txt

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