Network Working Group
`Request for Comments: 1541
`Obsoletes: 1531
`
`Category: Standards Track
`
`R. Droms
`Bucknell University
`October 1993
`
`Dynamic Host Configuration Protocol
`
`Status of this memo
`
`This RFC specifies an Internet standards track protocol for the
`Internet community, and requests discussion and suggestions for
`improvements.
`Please refer to the current edition of the "Internet
`O""icial Protocol Standards" for the standardization state and status
`
`of this protocol. Distribution of this memo is unlimited.
`
`Abstract
`
`(DHCP) provides a framework
`The Dynamic Host Configuration Protocol
`for passing configuration information to hosts on a TCP/IP network.
`DHCP is based on the Bootstrap Protocol
`(BOOTP)
`[7], adding the
`I1
`capability of automatic allocation of reusable network addresses and
`additional configuration options [19].
`DHCP captures the behavior o;
`BOOTP relay agents [7, 23], and DHCP participants can interoperate
`with BOOTP participants [9].
`Due to some errors introduced into RFC
`1531 in the editorial process,
`this memo is reissued as RFC 1541.
`
`Table of Contents
`
`Introduction.
`1.
`1.1 Related Work.
`1.2 Problem definition and issues
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`1.3 Requirements.
`1.4 Terminology
`1.5 Design goals.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`2. Protocol Summary .
`.
`.
`2.1 Configuration parameters repository .
`2.2 Dynamic allocation of network addresses .
`3. The Client—Server Protocol
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`2
`4
`4
`
`.
`
`.
`
`5
`6
`6
`8
`.
`. 10
`. 11
`. 11
`
`. 12
`
`. 17
`
`. 19
`. 19
`. 20
`. 20
`
`. 21
`
`.
`3.1 Client—server interaction — allocating a network address.
`3.2 Client—server interaction — reusing a previously allocated
`network address .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`3.3 Interpretation and representation of time values.
`3.4 Host parameters in DHCP .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`3.5 Use of DHCP in clients with multiple interfaces .
`3.6 When clients should use DHCP.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`4. Specification of the DHCP client—server protocol
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`Droms
`
`[Page 1]
`
`Page 1 of 40
`
`LG Electronics Exhibit 1013
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`4.1 Constructing and sending DHCP messages.
`4.2 DHCP server administrative controls .
`.
`4.3 DHCP server behavior.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`4.3.1 DHCPDISCOVER message.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`4.3.2 DHCPREQUEST message .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`4.3.3 DHCPDECLINE message .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`4.3.4 DHCPRELEASE message .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`4.4 DHCP client behavior.
`.
`4.4.1 Initialization and allocation of network address.
`4.4.2 Initialization with known network address .
`.
`.
`.
`4.4.3 Initialization with a known DHCP server address .
`
`4.4.4 Reacquisition and expiration.
`4.4.5 DHCPRELEASE .
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`. 21
`. 23
`. 24
`
`. 24
`. 27
`. 29
`. 29
`. 29
`. 29
`. 33
`. 34
`
`. 34
`. 35
`
`. 35
`. 36
`
`5. Acknowledgments.
`6. References .
`.
`.
`
`7. Security Considerations.
`8. Author's Address .
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`A. Host Configuration Parameters
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`. 37
`. 38
`
`. 39
`
`List of Figures
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1. Format of a DHCP message .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`2. Format of the 'flags' field.
`3. Timeline diagram of messages exchanged between DHCP client and
`servers when allocating a new network address.
`.
`.
`.
`.
`.
`.
`.
`. 15
`4. Timeline diagram of messages exchanged between DHCP client and
`servers when reusing a previously allocated network address.
`. 18
`5. State—transition diagram for DHCP clients.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. 31
`
`9
`1O
`
`List of Tables
`
`1. Description o" "ields in a DHCP message.
`2. DHCP messages.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`3. Fields and options used by DHCP servers.
`4. Fields and options used by DHCP clients.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`. 14
`. 16
`. 25
`. 32
`
`1. Introduction
`
`(DHCP) provides configuration
`The Dynamic Host Configuration Protocol
`parameters to Internet hosts.
`DHCP consists of two components: a
`protocol for delivering host—specific configuration parameters from a
`DHCP server to a host and a mechanism for allocation of network
`addresses to hosts.
`
`DHCP is built on a clicnt—scrvcr modcl, whcrc dcsignated DHCP server
`hosts allocate network addresses and deliver configuration parameters
`to dynamically configured hosts. Throughout the remainder of this
`document,
`thc tcrm "scrvcr" rcfcrs to a host providing initialization
`
`Droms
`
`[Page 2]
`
`Page 2 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`parameters through
`requesting initialization parameters
`
`DHCP,
`
`and the term
`
`fers to a host
`"client"
`DHCP server.
`from a
`
`re
`
`A host should not act as a
`
`DHCP server unless explicitly configured
`The diversity o:5 hardware and
`to do so by a system administrator.
`protocol implementations in the Internet would preclude reliable
`DHCP requests.
`random hosts were allowed to respond to
`operation if
`For example,
`IP requires the setting of
`many parameters within the
`Because IP can be used on many
`protocol implementation software.
`values
`dissimilar kinds of network hardware,
`for those parameters
`faults. Also,
`cannot be guessed or assumed to have correct de:
`distributed address allocation schemes depend on a polling/defense
`IP
`for discovery of addresses that are already in use.
`mechanism
`so
`fend their network addresses,
`hosts may not always be able to de:
`that such a distributed address allocation scheme cannot be
`
`guaranteed to avoid allocation of
`
`duplicate network addresses.
`
`for IP address allocation.
`
`In
`
`mechanisms,
`
`A particular
`depending on the
`
`DHCP supports three mechanisms
`"automatic allocation",
`IP address to a
`DHCP assigns a permanent
`host.
`namic allocation",
`In "dy
`DHCP assigns an IP address to a host
`time
`for a limited period of
`(or until the host explicitly
`a host's IP
`In "manual allocation",
`relinquishes the address).
`and
`DHCP is used
`address is assigned by the network administrator,
`to the
`host.
`simply to convey the assigned address
`these
`network will use one or more of
`t
`he network administrator.
`
`policies of
`
`the three mechanisms that
`
`Dynamic allocation is the only one of
`allows automatic reuse of
`an address that is no longer needed by the
`Thus,
`host to which it was assigned.
`dynamic allocation is
`"ul
`particularly use
`"or assigning an address to a host that will be
`connected to the network only temporarily or
`for sharing a limited
`hosts that do not need
`pool of
`IP addresses among a group of
`permanent
`IP addresses.
`Dynamic allocation may also be a good choice
`for assigning an IP address to a new host being permanently connected
`to a network where IP addresses are su
`"iciently scarce that it is
`Manual
`important to reclaim them when old hosts are retired.
`allocation allows
`DHCP to be used to eliminate the error—prone
`ma
`process of
`nually configuring hosts with IP addresses in
`for whatever reasons)
`environments where (
`it is desirable to manage
`DHCP mechanisms.
`IP address assignment outside of the
`
`The format o‘
`
`DHCP messages is based on the format o‘
`‘ BOOTP messages,
`to capture the BOOTP relay agent behavior described as part of the
`cation [7, 23]
`BOOTP specifi
`and to allow interoperability of
`existing
`DHCP servers.
`BOOTP clients with
`Using BOOTP relaying agents
`having a
`DHCP server on each physical
`
`eliminates the necessity of
`network segment.
`
`Droms
`
`[Page 3]
`
`Page 3 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Con:figuration Protocol
`
`October 1993
`
`1.1 Related Work
`
`There are several Internet protocols and related mechanisms that
`The
`address some parts of
`the dynami
`c host configuration problem.
`Reverse Address Resolution Protocol
`(RARP)
`[10]
`(through the
`extensions de:
`fined in the
`c RARP (DRARP)
`Dynami
`[5]) explicitly
`and includes an
`addresses the problem o:
`f network address discovery,
`The
`Trivial File Transfer
`automatic IP address assignment mechanism.
`image from a
`Protocol
`(TFTP)
`[20] provides for transport of a boot
`boot server.
`The Internet Control Message Protocol
`(ICMP)
`[16]
`provides for informing hosts of additional routers via "ICMP
`redirect" messages.
`ICMP also can provide subnet mask information
`through the "ICMP mask request" message and other information through
`the
`Hosts can locate
`(obsolete)
`"ICMP in:
`formation request" message.
`routers through the ICMP router discovery mechanism
`
`[8]-
`
`for a collection o
`configuration
`and o
`"icial extensions
`
`BOOTP is a transport mechanism
`information.
`[17]
`'
`BOOTP is also extensible,
`have been de
`fined for several co
`Morgan has
`nfiguration parameters.
`[15].
`proposed extensions to BOOTP
`for dynamic IP address assignment
`The Network In:
`formation Protocol
`(NIP), used by
`the Athena project at
`is a distributed mechanism
`MIT,
`for dynamic IP address assignment
`The Resource Location Protocol RLP
`for location
`[1]
`[19].
`provides
`Off
`higher level services.
`Sun Microsystems diskless workstations use
`TFTP and an
`RPC mechanism called
`a boot procedure that employs RARP,
`"bootparams" to deliver configur
`ation information and operating
`Sun Workstation
`system code to diskless hosts.
`(Sun Microsystems,
`Some Sun
`and SunOS are trademarks of
`Inc.)
`Sun Microsystems,
`networks also use DRARP and an auto—installation mechanism to
`automate the con:
`
`figuration of
`
`new hosts in an existing network.
`
`(MTU)
`the path minimum transmission unit
`In other related work,
`an
`discovery algorithm can determine the MTU of
`arbitrary internet
`Comer and
`path [14].
`Droms have proposed the use of the Address
`for resource
`Resolution Protocol
`(ARP)
`as a transport protocol
`location and selection
`[3,
`[6]-
`Finally,
`the Host Requirements RFCs
`for host recon:
`figuration and suggest
`4] mention speci:
`fic requirements
`a scenario
`for initial con:
`diskless hosts.
`figuration of
`
`1.2 Problem definition and issues
`
`figuration parameters
`DHCP is designed to supply hosts with the con:
`defined in the Host Requirements RFCs. After obtaining parameters
`via DHCP,
`a host should be able to exchange packets with any other
`host in the Internet.
`The parameters supplied by DHCP are listed in
`
`Appendix A.
`
`Droms
`
`[Page 4]
`
`Page 4 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Con:
`
`figuration Protocol
`
`October 1993
`
`Not all of
`host.
`
`these parameters are required
`A client and server may negotiate
`those parameters required by the client or speci:
`subnet.
`
`for a newly initialized
`for the transmission of
`
`only
`fic to a particular
`
`DHCP allows but does not require the con:
`not directly related to the IP protocol.
`newly con:
`registration of
`figured hosts with the
`(DNS)
`[12, 13].
`
`host parameters
`figuration o:
`DHCP also does not address
`
`Domain Name System
`
`DHCP is not intended
`
`for use in configuring routers.
`
`1.3 Requirements
`
`the words that are used to define the
`Throughout this document,
`These words
`significance of
`particular requirements are capitalized.
`are:
`
`"MUST"
`
`This word or the adjective "REQUIRED"
`item is an absolute requirement of
`this specification.
`
`means that the
`
`"MUST NOT"
`
`This phrase means that the item is an absolute prohibition
`fication.
`o
`this speci:
`
`"SHOULD"
`
`This word or the adjective "RECOMMENDE H means that there
`may exist valid reasons in particular circumstances to ignore
`this item, but the
`full implications should be understood and
`the case care:
`"erent course.
`fully weighed be:fore choosing a di
`
`"SHOULD NOT"
`
`This phrase means that there may exist valid reasons in
`particular circumstanccs whcn thc listcd bchavior is acceptable
`but the
`or even useful,
`full implications should be understood
`and the case care:
`fully wcighcd bc:
`forc implcmcnting any behavior
`described with this label.
`
`Droms
`
`[Page 5]
`
`Page 5 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`O IIMAY H
`
`This word or the adjective "OPTIONAL" means that this item is
`truly optional.
`One vendor may choose to include the item
`because a particular marketplace requires it or because it
`enhances the product,
`for example; another vendor may omit the
`same item.
`
`1.4 Terminology
`
`This document uses
`
`the following terms:
`
`is an Internet host using DHCP to obtain
`parameters such as a network address.
`
`is an Internet host that returns configuration
`DHCP clients.
`
`o "DHCP client"
`
`A C
`
`DHCP client
`OD
`
`figuration
`
`H’
`DHCP server"
`
`A
`
`DHCP server
`
`parameters to
`
`o "BOOTP relay agent"
`
`A BOOTP relay agent is an Internet host or router that passes
`DHCP servers.
`DHCP is
`DHCP messages between DHCP clients and
`designed to use the same relay agent behavior as specified in
`the BOOTP protocol specification.
`
`o "binding"
`
`including
`con"iguration parameters,
`A binding is a collection o
`at least an IP address, associated with or "bound to" a DHCP
`client. Bindings are managed by DHCP servers.
`
`1.5 Design goals
`
`The following list gives general design goals for DHCP.
`
`DHCP must
`o DHCP should be a mechanism rather than a policy.
`allow local system administrators control over configuration
`parameters where desired; e.g.,
`local system administrators
`should be able to enforce local policies concerning allocation
`and access to local rcsourccs whcrc dcsircd.
`
`Droms
`
`[Page 6]
`
`Page 6 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`Hosts should require no manual configuration.
`be able to discover appropriate local configuration parameters
`without user intervention and incorporate those parameters into
`its own configuration.
`
`Each host should
`
`Networks should require no hand configuration
`hosts.
`Under normal circumstances,
`the network manager should
`not have to enter any per—host configuration parameters.
`
`for individual
`
`DHCP should not rcquirc a scrvcr on cach subnet.
`DHCP must work
`scale and economy,
`across routers or through the
`intervention of BOOTP/DHCP relay agents.
`
`To allow for
`
`A r
`
`DHCP host must be prepared to receive multiple responses to a
`equest
`for configuration parameters.
`Some installations may
`DHCP servers to enhance
`include multiple, overlapping
`reliability and increase performance.
`
`configured, non—participating
`DHCP must coexist with statically
`hosts and with existing network protocol implementations.
`
`DHCP must
`
`interoperate with the BOOTP relay agent behavior as
`[21].
`described by RFC 951 and by Wimer
`
`DHCP must
`
`provide service to existing BOOTP clients.
`
`The
`
`following list gives design goals specific to the transmission of
`DHCP must:
`the network layer parameters.
`
`0
`
`Guarantee that any specific network address will not be in
`use by more than one host at a time,
`
`A host should,
`Retain host configuration across host reboot.
`whenever possible, be assigned the same configuration parameters
`network address)
`(e-g-,
`in rcsponsc to cach rcqucst,
`
`and, whenever
`Retain host configuration across server reboots,
`possible,
`a host should be assigned the same configuration
`DHCP mechanism,
`parameters despite restarts of the
`
`con "iguration parameters to new
`Allow automatic assignment o
`for new hosts,
`hosts to avoid hand configuration
`
`Support
`fixed or permanent allocation o
`parameters to specific hosts.
`
`con"iguration
`
`Droms
`
`[Page 7]
`
`Page 7 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`2. Protocol Summary
`
`From the client's point of view, DHCP is an extension of the BOOTP
`mechanism. This behavior allows existing BOOTP clients to
`interoperate with DHCP servers without requiring any change to the
`clients‘ initialization software.
`A separate document details the
`interactions between BOOTP and DHCP clients and servers [9]. There
`are some new, optional transactions that optimize the interaction
`between DHCP clients and servers that are described in sections 3 and
`4.
`
`Figure 1 gives the format of a DHCP message and table 1 describes
`each o" the "ields in the DHCP message.
`The numbers in parentheses
`indicate the size of each field in octets.
`The names for the fields
`
`given in the figure will be used throughout this document to refer to
`the fields in DHCP messages.
`
`There are two primary di "erences between DHCP and BOOTP. First,
`DHCP defines mechanisms through which clients can be assigned a
`network address "or a "ixed lease, allowing for serial reassignment
`of network addresses to di""erent clients.
`Second, DHCP provides the
`mechanism for a client to acquire all of the IP configuration
`parameters that it needs in order to operate.
`
`DHCP introduces a small change in terminology intended to clarify the
`meaning of one o" the "ields. What was the "vendor extensions" field
`in BOOTP has been re—named the "options" field in DHCP. Similarly,
`the tagged data items that were used inside the BOOTP "vendor
`extensions" field, which wcrc formcrly rcfcrrcd to as "vendor
`extensions," are now termed simply "options."
`
`DHCP defines a new ‘client identifier‘ option that is used to pass an
`explicit client identifier to a DHCP server. This change eliminates
`the overloading of the 'chaddr' field in BOOTP messages, where
`'chaddr'
`is used both as a hardware address for transmission of BOOTP
`
`The ‘client identifier‘
`reply messages and as a client identifier.
`option may contain a hardware address,
`identical to the contents of
`the 'chaddr' field, or it may contain another type of identifier,
`such as a DNS name. Othcr clicnt idcntificr typcs may be defined as
`needed for use with DHCP.
`Ncw clicnt idcntificr typcs will be
`registered with the IANA [18] and will be included in new revisions
`of the Assigned Numbers document, as well as described in detail in
`future revisions of the DHCP Options [2].
`
`Droms
`
`[Page 8]
`
`Page 8 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`3
`2
`1
`O
`5 6 7 8 9 O 1
`1 2 3 4
`9 O
`5 6 7 8
`1 2 3 4
`1 2 3 4 5 6 7 8 9 O
`O
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`I
`(1)
`hops
`I
`hlen (1)
`I
`htype (1)
`I
`(1)
`Op
`I
`+ ————————————— ——+ ————————————— ——+ ————————————— ——+ ————————————— ——+
`
`I
`Xid (4)
`I
`+ ————————————————————————————— ——+ ————————————————————————————— ——+
`
`I
`flags (2)
`I
`secs (2)
`I
`+ ————————————————————————————— ——+ ————————————————————————————— ——+
`
`I
`(4)
`ciaddr
`I
`+ ————————————————————————————————————————————————————————————— ——+
`
`I
`(4)
`yiaddr
`I
`+ ————————————————————————————————————————————————————————————— ——+
`
`I
`(4)
`siaddr
`I
`+ ————————————————————————————————————————————————————————————— ——+
`
`I
`(4)
`giaddr
`I
`+ ————————————————————————————————————————————————————————————— ——+
`
`I
`I
`I
`I
`I
`I
`I
`I
`+ ————————————————————————————————————————————————————————————— ——+
`
`chaddr
`
`(16)
`
`I
`I
`I
`(64)
`sname
`I
`+ ————————————————————————————————————————————————————————————— ——+
`
`I
`I
`I
`(128)
`file
`I
`+ ————————————————————————————————————————————————————————————— ——+
`
`I
`I
`I
`options (312)
`I
`+ ————————————————————————————————————————————————————————————— ——+
`
`Figure 1:
`
`Format of a DHCP message
`
`DHCP clarifies the interpretation of the 'siaddr' field as the
`address of the server to use in the next step of the client's
`bootstrap process.
`A DHCP server may return its own address in the
`'siaddr' field, if the server is prepared to supply the next
`bootstrap service (e.g., delivery of an operating system executable
`image).
`A DHCP server always returns its own address in the ‘server
`identifier‘ option.
`
`The options field is now variable length, with the minimum extended
`to 312 octets. This brings the minimum size of a DHCP message up to
`576 octets,
`the minimum IP datagram size a host must be prepared to
`accept
`[3].
`DHCP clients may negotiate the use of larger DHCP
`messages through the ‘Maximum DHCP message size‘ option.
`The options
`field may be further extended into the ‘file‘ and ‘sname‘ fields.
`
`Droms
`
`[Page 9]
`
`Page 9 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`A new option,
`called ‘vendor speci"ic in"ormation‘,
`allow
`the number of
`for expansion of
`options that can be supported
`‘vendor speci"ic in"ormation‘ must be
`[2]-
`Options encapsulated as
`as to allow
`carefully defined and documented so
`for interoperability
`between clients and servers
`from diferent vendors.
`In particular,
`MUST document those
`
`has been added to
`
`vendors defining ‘vendor speci"ic in"ormation‘
`"orm o" the
`options in the
`DHCP Options document, MUST choose to
`O1"
`represent those options either in data types already de"ined
`options or in other well—defined data types,
`and MUST choose options
`"iles "or exchange with
`that can be readily encoded in configuration
`Options included as ‘vendor
`servers provided by other vendors.
`specific options‘ MUST be readily supportable by all servers.
`
`DHCP
`
`1
`1
`1
`1
`1
`1
`8 9 O 1 2 3 4 5
`6 7
`O 1 2 3 4 5
`—+—+—+—+—+-+—+—+—+—+—+—+—+—+—+—+
`
`|
`MBZ
`Bl
`—+—+—+—+—+-+—+—+—+—+—+—+—+—+—+—+
`
`B:
`
`BROADCAST flag
`
`MBZ: MUST BE ZERO (reserved "or "uture use)
`
`Figure 2:
`
`Format of the ‘flags‘ field
`
`The leftmost bit is defined as the
`DHCP uses the ‘flags‘ field [21].
`BROADCAST (B) flag.
`The semantics of this flag are discussed in
`section 4.1 of this document.
`The remaining bits o" the "lags "ield
`are reserved "or "uture use.
`They MUST be set to zero by clients and
`ignored by servers and relay agents.
`Figure 2 gives the format of
`the ‘ flags‘ field.
`
`2.1 Configuration parameters repository
`
`The first
`of
`
`service provided by
`DHCP is to provide persistent storage
`DHCP
`The model of
`for network clients.
`network parameters
`persistent storage is that the
`DHCP service stores a key-value entry
`"or
`for each client, where the key is some unique identi"ier (
`fier within the
`example,
`an IP subnet number and a unique identi
`for the
`and the value contains the con:
`subnet)
`figuration parameters
`client.
`
`hardware-
`(IP—subnet—number,
`For example,
`the key might be the pair
`a hardware
`for serial or concurrent reuse of
`address),
`allowing
`address on di
`""erent subnets, and
`for hardware addresses that may not
`(IP-
`Alternately,
`the key might be the pair
`be globally unique.
`subnet—number,
`hostname),
`allowing the server to assign parameters
`"erent subnet or
`intelligently to a host that has been moved to a di
`
`Droms
`
`[Page 10]
`
`Page 10 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`has changed hardware addresses (perhaps because the network interface
`failed and was replaced).
`
`A client can query the DHCP service to retrieve its configuration
`parameters.
`The client interface to the configuration parameters
`repository consists of protocol messages to request configuration
`parameters and responses from the server carrying the configuration
`parameters.
`
`2.2 Dynamic allocation of network addresses
`
`The second service provided by DHCP is the allocation of temporary or
`permanent network (IP) addresses to hosts.
`The basic mechanism for
`the dynamic allocation of network addresses is simple: a client
`requests the use of an address for some period of time.
`The
`allocation mechanism (the collection of DHCP servers) guarantees not
`to reallocate that address within the requested time and attempts to
`return the same network address each time the client requests an
`address.
`In this document,
`the period over which a network address
`is allocated to a client is referred to as a "lease" [11].
`The
`client may extend its lease with subsequent requests.
`The client may
`issuc a mcssagc to rclcasc thc addrcss back to the server when the
`client no longer needs the address.
`The client may ask for a
`permanent assignment by asking for an infinite lease.
`Even when
`assigning "permanent" addresses, a server may choose to give out
`lengthy but non—infinite leases to allow detection o" the "act that
`the host has been retired.
`
`In some environments it will be necessary to reassign network
`addresses due to exhaustion of available addresses.
`In such
`
`the allocation mechanism will reuse addresses whose
`environments,
`lease has expired.
`The server should use whatever information is
`available in the configuration information repository to choose an
`address to reuse.
`For example,
`the server may choose the least
`recently assigned address. As a consistency check,
`the allocation
`mechanism may probe the reused address, e.g., with an ICMP echo
`request, before allocating the address, and the client will probe the
`newly received address, e.g., with ARP.
`
`3. The C1ient—Server Protocol
`
`DHCP uses the BOOTP message format defined in RFC 951 and given in
`table 1 and figure 1.
`The 'op' field of each DHCP message sent from
`a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
`'op' field of each DHCP message sent from a server to a client.
`
`The "irst "our octets of the 'options' field of the DHCP message
`contain the (decimal) values 99, 130, 83 and 99, respectively (this
`
`Droms
`
`[Page 11]
`
`Page 1 1 of 40
`
`

`
`RFC 15
`
`41
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`is
`of
`cal
`are
`
`opt
`
`the same magic cookie as is defined in RFC 1497).
`field consists a list of
`tagged parameters that are
`the ‘options’
`the
`"vendor extensions
`" listed in RFC 1497
`led "options". All of
`also DHCP options.
`A separate document gives the complete set of
`DHCP
`ions de"ined "or use with
`[2]-
`
`The remainder
`
`Several options have been de:
`far. One particular option —
`H’
`DHCP
`the
`JHCP message type" option - must be included in every
`mes
`sage.
`DHCP message.
`This option defines the "type" of the
`or not allowed,
`Additional options may be allowed,
`required,
`dep
`ending on the DHCP message type.
`
`fined so
`
`Thr
`
`DHCP message
`DHCP messages that include a ‘
`oughout this document,
`type‘ option will be referred to by the type of the message; e.g., a
`DHCP message with ‘DHCP message type‘ option type 1 will be referred
`to as a "DHCPDISCOVER" message.
`
`3.1 Client—server interaction — allocating a network address
`
`The following summary of the protocol exchanges between clients and
`servers refers to the DHCP messages described in table 2.
`The
`timeline diagram in
`figure 3 shows the timing relationships in a
`If the client already knows its
`ical client—server interaction.
`typ
`address,
`some steps may be omitted;
`this abbreviated interaction is
`des
`cribed in section 3.2.
`
`The client broadcasts a
`DHCPDISCOVER message on its local physical
`subnet.
`The
`DHCPDISCOVER message may include options that suggest
`values
`for the network address and lease duration.
`BOOTP relay
`DHCP servers not on the same
`
`agents may pass the message on to
`physical subnet.
`
`Each server may respond with a
`DHCPOFFER message that includes an
`available network address in the
`field (and other
`‘yiaddr‘
`Servers need not
`DHCP options).
`configuration parameters in
`rcscrvc thc o"
`"crcd nctwork address, although the protocol will
`work more e" "iciently if
`"ered
`the server avoids allocating the o"
`network address to another client.
`The server unicasts the
`
`(using the
`DHCPOFFER message to the client
`DHCP/BOOTP relay agent
`
`i
`if necessary)'
`f possible,
`or may broadcast the message to a
`broadcast address
`on the client's
`(preferably 255.255.255.255)
`subnet.
`
`Thc clicnt rcccivcs onc or more
`more servers.
`
`responses.
`
`DHCPOFFER messages
`The client may choose to wait
`for multiple
`The client chooses one server
`from which to request
`based on the configuration parameters
`configuration parameters,
`The client broadcasts a
`o""ered in the
`DHCPOFFER messages.
`
`from one or
`
`Droms
`
`[Page 12]
`
`Page 1
`
`20f40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`'scrvcr idcntificr'
`
`DHCPREQUEST message that MUST includc thc
`option to indicate which server it has selected,
`and may include
`This
`other options specifying desired configuration values.
`DHCP/BOOTP
`DHCPREQUEST message is broadcast and relayed through
`relay agents.
`To help ensure that any
`DHCP/BOOTP relay agents
`forward the
`same set of DHCP servers
`DHCPREQUEST message to the
`DHCPDISCOVER
`the DHCPREQUEST
`message,
`that received the original
`DHCP message header's
`message must use the same value in the
`'secs'
`field and be sent to the same IP broadcast address as the
`The client times out and
`the client receives no
`
`DHCPDISCOVER message.
`original
`retransmits the
`DHCPDISCOVER message if
`DHCPOFFER messages.
`
`4.
`
`Thc scrvcrs rcccivc thc
`
`from the client.
`
`DHCPREQUEST broadcast
`Those servers not selected by the
`DHCPREQUEST message use the
`fication that the client has declined that server's
`message as noti:
`o "er.
`The server selected in the
`
`DHCPREQUEST message commits the
`for the client to persistent storage and responds with a
`binding
`for the
`JHCPACK message containing the con:
`figuration parameters
`The combination OT
`'chaddr' and assigned
`requesting client.
`"ier "or the client's
`network address constitute an unique identi
`lease and are used by both the client and server to identify a
`DHCP messages.
`lease referred to in any
`The 'yiaddr' field in the
`selected network address.
`filled in with the
`DHCPACK messages is
`
`I (
`
`DHCPREQUEST message
`the selected server is unable to satisfy the
`the
`e-g-,
`the requested network address has been allocated),
`DHCPNAK message.
`server SHOULD respond with a
`
`"ered to clients in
`A server may choose to mark addresses o
`The server should mark an
`DHCPOFFER messages as unavailable.
`address o
`"ered to a client in a
`DHCPOFFER message as available if
`the server receives 1'10
`DHCPREQUEST mess
`age from that client.
`
`Droms
`
`[Page 13]
`
`Page 13 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`OCTETS
`
`DESCRIPTION
`
`htype
`
`hlen
`
`hops
`
`Xid
`
`SGCS
`
`flags
`ciaddr
`
`yiaddr
`siaddr
`
`giaddr
`
`chaddr
`sname
`
`file
`
`options
`
`Message op code / message type.
`1 = BOOTREQUEST,
`2
`BOOTREPLY
`Hardware address type, see ARP section in "Assigned
`Numbers" RFC; e.g.,
`'1'
`10mb ethernet.
`Hardware address length (e.g.
`'6' for 10mb
`ethernet).
`Client sets to zero, optionally used by relay—agents
`when booting via a relay—agent.
`Transaction ID, a random number chosen by the
`client, used by the client and server to associate
`messages and responses between a client and a
`server.
`
`Filled in by client, seconds elapsed since client
`started trying to boot.
`Flags (see figure 2).
`Client IP address; filled in by client in
`DHCPREQUEST i" veri"ying previously allocated
`configuration parameters.
`'your'
`(client)
`IP address.
`IP address of next server to use in bootstrap;
`returned in DHCPOFFER, DHCPACK and DHCPNAK by
`server.
`
`16
`64
`128
`
`312
`
`Relay agent IP address,
`relay—agent.
`Client hardware address.
`
`used in booting via a
`
`Optional server host name,
`null terminated string.
`Boot file name, null terminated string; "generic"
`name or null in DHCPDISCOVER, fully qualified
`directory—path name in DHCPOFFER.
`Optional parameters field.
`See the options
`documents for a list o" de"ined options.
`
`Table 1:
`
`Description o
`
`"ields in a
`
`DHCP message
`
`Droms
`
`[Page 14]
`
`Page 14 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`Server
`
`Client
`
`(not selected)
`
`Server
`
`(selected)
`
`v I I I I
`
`v
`
`I
`Begins initialization
`
`/I\
`/ DHCPDISCOVER I DHCPDISCOVER \|
`
`V I
`
`I I I I I
`
`Determines
`
`configuration
`
`Determines
`
`configuration
`
`\
`
`DHCPOFFER\
`
`/
`
`I\
`I
`I
`I
`I
`I
`I
`I
`I
`I / DHCPREQUEST
`I
`I
`I
`I
`I
`
`\
`Collects replies
`\I
`Selects configuration
`I
`/I\
`I
`I
`I
`I
`I
`I / DHCPACK
`
`/DHCPOFFER
`
`/I
`I
`I
`I
`I
`I
`I
`I
`I
`DHCPREQUE ST \ I
`I
`Commits configuration
`I
`
`/
`
`Initialization complete
`
`I
`Graceful shutdown
`
`DHCPREDEASE \|
`
`Discards lease
`I
`V
`
`\
`
`I I I I
`
`I
`v
`
`I I I
`
`I I I I I I I IV
`
`Figure 3: Timeline diagram of messages exchanged between DHCP
`client and servers when allocating a new network address
`
`Droms
`
`[Page 15]
`
`Page 15 of 40
`
`

`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`Use
`
`DHCPDISCOVER
`
`Client broadcast to locate available servers.
`
`DHCPOFFER
`
`DHCPREQUEST
`
`DHCPACK
`
`DHCPNAK
`
`DHCPDECLINE
`
`DHCPRELEASE
`
`Server to client in response to DHCPDISCOVER with
`o "er o
`"
`con"iguration parameters.
`
`Client broadcast to servers requesting o "ered
`parameters from one server and implicitly declining
`o""ers "rom all others.
`
`Server to client with configuration parameters,
`including committed network address.
`
`Server to client refusing request for configuration
`parameters (e.g., requested network address already
`allocated).
`
`Client to server indicating configuration parameters
`(e.g., network address)
`invalid.
`
`Client to server relinquishing network address and
`cancelling remaining lease.
`
`Table 2:
`
`DHCP messages
`
`5. Thc clicnt rcccivcs thc
`
`DHCPACK message with configuration
`parameters.
`The client performs a final check on the parameters
`ARP
`and notes the duration
`for allocated network address),
`(e-g-,
`O:
`the lease and the lease identification cookie specified in the
`the
`DHCPACK message.
`At this point,
`the client is configure