>
`
`Page 1 of37
`
`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
`Official 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
`capability of automatic allocation of reusable network addresses and
`additional configuration options [19].
`DHCP captures the behavior of
`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
`.
`.
`.
`.
`.
`.
`.
`.
`.
`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
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`2
`4
`4
`
`5
`6
`6
`8
`.
`. 10
`. 11
`. 11
`. 12
`
`. 17
`
`. 19
`. 19
`. 20
`. 20
`. 21
`
`Droms
`
`[Page 1]
`
`fi1e:///C :/Users/254 74/AppData/Loca1/Temp/Low/G}H(ZIR3 J.htm
`
`12/ 17/2013
`
`Page 1 of 37
`
`Verizon Exhibit 1013
`
`

`
`Page 2 of 37
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`.
`.
`.
`.
`.
`.
`1.1 Constructing and sending DHCP messages.
`.
`.
`.
`.
`.
`.
`1.2 DHCP server administrative controls .
`.
`.
`.
`.
`.
`.
`.
`1.3 DHCP server behavior.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1.3.1 DHC?D1SCOV3R message.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1.3.2 DHC?R3QUEST message .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1.3.3 DHC?D?CL1N? message .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1.3.4 DHC?R3LEAS3 message .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1.4 DHCP client behavior.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1.4.1 1ni:ializa:ion and allocation of network address.
`1.4.2 1ni:ializa:ion with known network address .
`.
`.
`.
`1.4.3 1ni:ializa:ion with a known DHCP server address .
`1.4.4 Reacquisition and expiration.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1.4.5 DHC?RELEAS3 .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`5. Acknowledgmen:s.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`6. References .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`7. Securi:y Considerations.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`8. Author's Address .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`A. Host Configuration Parameters
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`. 21
`. 23
`. 24
`. 24
`. 27
`. 29
`. 29
`. 29
`. 29
`. 33
`. 34
`. 34
`. 35
`. 35
`. 36
`. 37
`. 38
`. 39
`
`List of Figures
`
`9
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1. Format of a DHCP message .
`. 10
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`2. Format of the 'flags' field.
`3. Timeline diagram of m ssag s Xchang d b tw n DHCP client and
`servers when allocating a new network address.
`.
`.
`.
`.
`.
`.
`.
`. 15
`4. Timeline diagram of m ssag s Xchang d b tw n DHCP client and
`servers when reusing a previously allocated network address.
`. 18
`5. State—transition diagram for DHCP clients.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. 31
`
`List of Tables
`
`1. Description of fields 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.
`
`d signat d DHCP server
`DHCP is built on a cli nt—s rv r mod l, wh r
`hosts allocate network addresses and deliver configuration parameters
`to dynamically configured hosts. Throughout the remainder of this
`docum nt,
`th t rm "s rv r" r f rs to a host providing initialization
`
`Droms
`
`[Page 2]
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`parameters through DHCP, and the term "client" refers to a host
`
`fi1e:///C :/Users/254 74/AppData/Loca1/Temp/Low/GHKZIR3 J.htm
`
`12/ 17/2013
`
`Page 2 of 37
`
`

`
`Page 3 of 37
`
`requesting initialization parameters from a DHCP server.
`
`A host should not act as a DHCP server unless explicitly configured
`to do so by a system administrator.
`The diversity of hardware and
`pro:ocol implementations in the Internet would preclude reliable
`operation if random hosts were allowed to respond to DHCP requests.
`For
`xampl
`,
`IP r quir s th s tting of many parameters within the
`pro:ocol implementation software. Because IP can be used on many
`dissimilar kinds of network hardware, values for those parameters
`cannot be guessed or assumed to have correct defaults. Also,
`dis:ributed address allocation schemes depend on a polling/defense
`mecianism for discovery of addresses that are already in use.
`IP
`hos:s may not always b
`abl
`to d f nd th ir n twork addresses,
`so
`tha: such a distributed address allocation scheme cannot be
`guaranteed to avoid allocation of duplicate network addresses.
`
`In
`DHC? supports three mechanisms for IP address allocation.
`"au:omatic allocation", DHCP assigns a permanent IP address to a
`hos:.
`In "dynamic allocation", DHCP assigns an IP address to a host
`for a limited period of time (or until the host explicitly
`relinquishes the address).
`In "manual allocation", a host's IP
`address is assigned by the network administrator, and DHCP is used
`simply to convey the assigned address to the host.
`A particular
`network will use one or more of these mechanisms, depending on the
`policies of the network administrator.
`
`Dynamic allocation is the only one of the three mechanisms that
`allows automatic reuse of an address that is no longer needed by the
`host to which it was assigned. Thus, dynamic allocation is
`particularly useful for assigning an address to a host that will be
`connected to the network only temporarily or for sharing a limited
`pool of IP addresses among a group of hosts that do not need
`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 sufficiently scarce that it is
`important to reclaim them when old hosts are retired. Manual
`allocation allows DHCP to be used to eliminate the error—prone
`process of manually configuring hosts with IP addresses in
`environments where (for whatever reasons) it is desirable to manage
`IP address assignment outside of the DHCP mechanisms.
`
`The format of DHCP messages is based on the format of BOOTP messages,
`to capture the BOOTP relay agent behavior described as part of the
`BOOTP specification [7, 23] and to allow interoperability of existing
`BOOTP clients with DHCP servers. Using BOOTP relaying agents
`eliminates the necessity of having a DHCP server on each physical
`network segment.
`
`Droms
`
`[Page 3]
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`1.1 Related Work
`
`There are several Internet protocols and related mechanisms that
`address some parts of the dynamic host configuration problem.
`The
`Reverse Address Resolution Protocol
`(RARP)
`[10]
`(through the
`
`fi1e:///C :/Users/25474/AppData/Loca1/Temp/Low/GHKZIR3J.htm
`
`12/ 17/2013
`
`Page 3 of 37
`
`

`
`Page 4 of 37
`
`[5]) explicitly
`extensions defined in the Dynamic RARP (DRARP)
`addresses the problem of network address discovery, and includes an
`automatic IP address assignment mechanism.
`The Trivial File Transfer
`Protocol
`(TFTP)
`[20] provides for transport of a boot
`image from a
`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 (obsolete)
`"ICMP information request" message. Hosts can locate
`routers through the ICMP router discovery mechanism [8].
`
`BOOTP is a transport mechanism for a collection of configuration
`information.
`BOOTP is also extensible, and official extensions [17]
`have been defined for several configuration parameters. Morgan has
`proposed extensions to BOOTP for dynamic IP address assignment
`[15].
`The Network Information Protocol
`(NIP), used by the Athena project at
`MIT,
`is a distributed mechanism for dynamic IP address assignment
`[19].
`The Resource Location Protocol RLP [1] provides for location
`of higher level services.
`Sun Microsystems diskless workstations use
`a boot procedure that employs RARP, TFTP and an RPC mechanism called
`"bootparams" to deliver configuration information and operating
`system code to diskless hosts.
`(Sun Microsystems, Sun Workstation
`and SunOS are trademarks of Sun Microsystems,
`Inc.)
`Some Sun
`networks also use DRARP and an auto—installation mechanism to
`automate the configuration of new hosts in an existing network.
`
`(MTU)
`the path minimum transmission unit
`In other related work,
`discovery algorithm can determine the MTU of an arbitrary internet
`path [14].
`Comer and Droms have proposed the use of the Address
`Resolution Protocol
`(ARP) as a transport protocol for resource
`[3,
`location and selection [6]. Finally,
`the Host Requirements RFCs
`4] mention specific requirements for host reconfiguration and suggest
`a scenario for initial configuration of diskless hosts.
`
`1.2 Problem definition and issues
`
`DHCP is designed to supply hosts with the configuration parameters
`defined in the Host Requirements RFCs. After obtaining parameters
`via DHCP, a host should b
`abl
`to xchang pack ts with any other
`host in th Int rn t.
`Th
`param t rs supplied by DHCP are listed in
`Appendix A.
`
`Droms
`
`[Page 4]
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`Not all of these parameters are required for a newly initialized
`host.
`A client and server may negotiate for the transmission of only
`those parameters required by the client or specific to a particular
`subnet.
`
`DHCP allows but does not require the configuration of host parameters
`not directly related to the IP protocol.
`DHCP also does not address
`registration of newly configured hosts with the Domain Name System
`(DNS)
`[12, 13].
`
`fi1e:///C :/Users/25474/AppData/Loca1/Temp/Low/GHKZIR3J.htm
`
`12/ 17/2013
`
`Page 4 of 37
`
`

`
`Page 5 of 37
`
`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" means that the
`item is an absolute requirement of this specification.
`
`"MUST NOT"
`
`This pirase means that the item is an absolute prohibition
`of this specification.
`
`" SHOUL 3"
`
`This word or the adjective "RECOMMENDED" means that there
`may exist valid reasons in particular circumstances to ignore
`this i:em, but the full implications should be understood and
`the case carefully weighed before choosing a different course.
`
`" SHOUL 3 NOT"
`
`This pirase means that there may exist valid reasons in
`particular circumstances when the listed behavior is acceptable
`or even useful, but the full implications should be understood
`and the case carefully weighed before implementing any behavior
`described with this label.
`
`Droms
`
`RFC 1541
`
`0
`
`"MAY II
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`[Page 5]
`
`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:
`
`0
`
`"DHCP client"
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/G}H(ZIR3J.htm
`
`12/17/2013
`
`Page 5 of 37
`
`

`
`Page 6 of 37
`
`A DHCP client
`configuration
`
`o "DHCP server"
`
`A DHCP server
`parameters to
`
`is an Internet host using DHCP to obtain
`parameters such as a network address.
`
`is an Internet host that returns configuration
`DHCP clients.
`
`o "BOOTP relay agent"
`
`A BOOTP relay agent is an Internet host or router that passes
`DHCP messages between DHCP clients and DHCP servers.
`DHCP is
`designed to us
`th sam r lay ag nt b havior as specified in
`the BOOTP protocol specification.
`
`o "binding"
`
`A binding is a collection of configuration parameters,
`at least an IP address, associated with or "bound to"
`client. Bindings are managed by DHCP servers.
`
`including
`a DHCP
`
`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 resources where desired.
`
`Droms
`
`[Page 6]
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`Each host should
`o 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.
`
`o Networks should require no hand configuration for individual
`hosts. Under normal circumstances,
`the network manager should
`not have to enter any per—host configuration parameters.
`
`To allow for
`o DHCP should not require a server on each subnet.
`scale and economy, DHCP must work across routers or through the
`intervention of BOOTP/DHCP relay agents.
`
`o A DHCP host must be prepared to receive multiple responses to a
`request for configuration parameters.
`Some installations may
`include multiple, overlapping DHCP servers to enhance
`reliability and increase performance.
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/G}H(ZIR3J.htm
`
`12/17/2013
`
`Page 6 of 37
`
`

`
`Page 7 of 37
`
`o DHCP must coexist with statically configured, non—participating
`hosts and with existing network protocol implementations.
`
`o DHCP must interoperate with the BOOTP relay agent behavior as
`described by RFC 951 and by Wimer
`[21].
`
`o DHCP must provide service to existing BOOTP clients.
`
`The following list gives design goals specific to the transmission of
`the network layer parameters.
`DHCP must:
`
`o Guarantee that any specific network address will not be in
`use by more than one host at a time,
`
`A host should,
`o Retain host configuration across host reboot.
`whenever possible, be assigned the same configuration parameters
`(e.g., network address)
`in response to each request,
`
`o Retain host configuration across server reboots, and, whenever
`possible, a host should be assigned the same configuration
`parameters despite restarts of the DHCP mechanism,
`
`o Allow automatic assignment of configuration parameters to new
`hosts to avoid hand configuration for new hosts,
`
`o Support fixed or permanent allocation of configuration
`parameters to specific hosts.
`
`Droms
`
`[Page 7]
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`2. Protocol Summary
`
`From the client's point of view, DJCP is an extension of the BOOTP
`mechanism. This behavior allows existing BOOTP clients to
`interoperate with DHCP servers witiout requiring any change to the
`clients‘ initialization softwar .
`A s parat
`docum nt d tails the
`interactions between BOOTP and DHC? clients and servers [9]. There
`are some new, optional transactions that optimize the interaction
`between DHCP clients and servers tiat are described in sections 3 and
`4.
`
`Figure 1 gives the format of a DHC? message and table 1 describes
`each of the fields in the DHCP message.
`The numbers in parentheses
`indicate the size of each field in octets.
`The names for the fields
`given in the figure will be used tiroughout this document to refer to
`the fields in DHCP messages.
`
`There are two primary differences between DHCP and BOOTP. First,
`DHCP defines mechanisms through which clients can be assigned a
`network address for a fixed lease, allowing for serial reassignment
`of network addresses to different clients.
`Second, DHCP provides the
`
`fi1e:///C :/Users/25474/AppData/Loca1/Temp/Low/GHKZIR3J.htm
`
`12/ 17/2013
`
`Page 7 of 37
`
`

`
`Page 8 of 37
`
`mechanism for a client to acquire all of the IP configuration
`parameters that it needs in order to operate.
`
`DHCP introduces a small change in terminology intended to clarify the
`meaning of one of the fields. What was the "vendor extensions" field
`in BOOTP has been re—named the "options" field in DHCP. Similarly,
`the tagged data items that were used inside the BOOTP "vendor
`extensions" field, which were formerly referred to as "vendor
`extensions," are now termed simply "options."
`
`DHCP d fin s a n w 'cli nt id ntifi r' option that is used to pass an
`explicit client identifier to a DHCP server. This change eliminates
`the overloading of the 'chaddr' field in BOO”P messages, where
`'chaddr'
`is used both as a hardware address for transmission of BOOTP
`reply messages and as a cli nt id ntifi r.
`“h
`'cli nt id ntifi r'
`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 nam . Oth r cli nt id ntifi r typ s may be defined as
`needed for use with DHCP.
`N w cli nt id ntifi r typ s will be
`registered with the IANA [18] and will be included in new revisions
`of the Assigned Numbers document, as well as described in detail in
`future revisions of the DHCP Options [2].
`
`Droms
`
`[Page 8]
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`3
`2
`1
`0
`1
`5 6 7 8 9 0
`1 2 3 Z
`1 2 3 4 5 6 7 8 9 0
`1 2 3 4 5 6 7 8 9 0
`0
`~—+—+—+—+—+—+—+—~—+—+—+—+—+—+—+—~—+—+—+—+—+—+—+—~—+—+—+—+—+—+—+——
`
`op (1)
`
`htype (1)
`
`hlen (1)
`
`hops
`
`(1)
`
`Xic
`
`(4)
`
`secs (2)
`
`flags (2)
`
`ciadcr
`
`(4)
`
`yiadcr
`
`siadcr
`
`(4)
`
`(4)
`
`giadcr
`
`(4)
`
`chadcr
`
`(16)
`
`sname
`
`(64)
`
`fi1e:///C :/Users/254 74/AppData/Loca1/Temp/Low/GHKZIR3 J.htm
`
`12/ 17/2013
`
`Page 8 of 37
`
`

`
`Page 9 of 37
`
`Figure 1:
`
`Format of a DHCP message
`
`DHCP clarifies the interpretation of the 'siaddr' field as the
`address of the server to use in the next step of the client's
`bootstrap process.
`A DHCP server may return its own address in the
`'siaddr' field, if the server is prepared to supply the next
`bootstrap service (e.g., delivery of an operating system executable
`image).
`A DHCP server always returns its own address in the ‘server
`identifier‘ option.
`
`The options field is now variable length, with the minimum extended
`to 312 octets. This brings the minimum size of a DHCP message up to
`576 octets,
`the minimum IP datagram size a host must be prepared to
`accept
`[3].
`DHCP clients may negotiate the use of larger DHCP
`messages through the ‘Maximum DHCP message size‘ option.
`The options
`field may be further extended into the ‘file‘ and ‘sname‘ fields.
`
`Droms
`
`[Page 9]
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`A new option, called ‘vendor specific information‘, has been added to
`allow for expansion of the number of options that can be supported
`[2]. Options encapsulated as ‘vendor specific information‘ must be
`carefully defined and documented so as to allow for interoperability
`between clients and servers from diferent vendors.
`In particular,
`vendors defining ‘vendor specific information‘ MUST document those
`options in the form of the DHCP Options document, MUST choose to
`represent those options either in data types already defined for DHCP
`options or in other well—defined data types, and MUST choose options
`that can be readily encoded in configuration files for exchange with
`servers provided by other vendors. Options included as ‘vendor
`specific options‘ MUST be readily supportable by all servers.
`
`1 1
`1
`1 1
`1
`0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
`————+———————+—+————+—+————+—+————————————
`B
`MBZ
`____+____,,____+____+_+_,,_+_+_,,_,__,,_,_
`
`B:
`
`BROADCAST flag
`
`MBZ: MUST BE ZERO (reserved for future use)
`
`Figure 2:
`
`Format of the ‘flags‘ field
`
`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 of the flags field
`are reserved for future use.
`They MUST be set to zero by clients and
`
`fi1e:///C :/Users/254 74/AppData/Loca1/Temp/Low/GHKZIR3 J.htm
`
`12/ 17/2013
`
`Page 9 of 37
`
`

`
`Page 10 of 37
`
`ignored by servers and relay agents. Figure 2 gives the format of
`the 'flags' field.
`
`2.1 Configuration parameters repository
`
`The first service provided by DHCP is to provide persistent storage
`of network parameters for network clients.
`The model of DHCP
`persistent storage is that the DHCP s rvic
`stor s a k y—valu
`for each client, where the key is some unique identifier (for
`example, an IP subnet number and a unique identifier within the
`subnet) and the value contains the configuration parameters for the
`client.
`
`ntry
`
`the key might be the pair (IP—subnet—number, hardware-
`For example,
`address), allowing for serial or concurrent reuse of a hardware
`address on different subnets, and for hardware addresses that may not
`be globally unique. Alternately,
`the key might be the pair (IP-
`subnet—number, hostname), allowing the server to assign parameters
`intelligently to a host that has been moved to a different subnet or
`
`Droms
`
`[Page 10]
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`has changed hardware addresses (perhaps because the network interface
`failed and was replaced).
`
`A client can query the DHCP service to retrieve its configuration
`parameters.
`Th cli nt int rfac
`to th 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
`issu a m ssag to r l as
`th addr ss 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 of the fact 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
`environments,
`the allocation mechanism will reuse addresses whose
`l as
`has xpir d.
`Th
`s rv r should use whatever information is
`available in the configuration information repository to choose an
`
`fi1e:///C :/Users/25474/AppData/Loca1/Temp/Low/GHKZIR3J.htm
`
`12/ 17/2013
`
`Page 10 of 37
`
`

`
`Page 11 of37
`
`the server may choose the least
`For example,
`address to reuse.
`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
`n wly r c iv d addr ss,
`.g., with ARP.
`
`3. The Client—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 first four octets of the 'options' field of the DHCP message
`contain the (decimal) values 99, 130, 83 and 99, respectively (this
`
`Droms
`
`[Page 11]
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`The remainder
`is the same magic cookie as is defined in RFC 1497).
`of the 'options' field consists a list of tagged parameters that are
`called "options". All of the "vendor extensions" listed in RFC 1497
`are also DHCP options.
`A s parat
`docum nt giv s th compl t
`s t of
`options defined for use with DHCP [2].
`
`Several options have been defined so far. One particular option —
`the "DHCP message type" option — must be included in every DHCP
`message. This option defines the "type" of the DHCP message.
`Additional options may be allowed, required, or not allowed,
`depending on the DHCP message type.
`
`Throughout this document, DHCP messages that include a ‘DHCP message
`type‘ option will be referred to by th typ of th m ssag ;
`.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
`typical client—server interaction.
`If the client already knows its
`address,
`some steps may be omitted; tiis abbreviated interaction is
`described in section 3.2.
`
`1. The client broadcasts a DHCPDISCOVER message on its local physical
`subnet.
`The DHCPDTSCOVER message may include options that suggest
`values for the network address and lease duration.
`BOOTP relay
`agents may pass the message on to DHCP servers not on the same
`physical subnet.
`
`2. Each server may respond with a DHCPOFFER message that includes an
`available network address in the 'yiaddr' field (and other
`configuration parameters in DHCP options).
`Servers need not
`reserve the offered network address, although the protocol will
`work more efficiently if the server avoids allocating the offered
`
`fi1e:///C :/Users/25474/AppData/Loca1/Temp/Low/GHKZIR3J.htm
`
`12/ 17/2013
`
`Page 11 of 37
`
`

`
`Page 12 of 37
`
`The server unicasts the
`network address to another client.
`DHCPOFFER message to the client
`(using the DHCP/BOOTP relay agent
`if necessary)
`if possible, or may broadcast the message to a
`broadcast address (preferably 255.255.255.255) on the client's
`subnet.
`
`3. The client receives one or more DHCPOFFER messages from one or
`more servers.
`The client may choose to wait for multiple
`responses.
`The client chooses one server from which to request
`configuration parameters, based on the configuration parameters
`offered in the DHCPOFFER messages.
`The client broadcasts a
`
`Droms
`
`[Page 12]
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`October 1993
`
`1
`DHCPR*QU?ST message that MUST include the ‘server identifier‘
`option to indicate which server it has selected, and may include
`other op:ions specifying desired configuration values. This
`DHCPR?QU?ST message is broadcast and relayed through DHCP/BOOTP
`relay agents.
`To help ensure that any DHCP/BOOTP relay agents
`forward :he DHCPREQUEST message to the same set of DHCP servers
`that received the original DHCPDISCOVER message,
`the DHCPREQUEST
`message must use the same value in the DHCP message header's
`'secs' field and be sent to the same IP broadcast address as the
`original DHCPDISCOVER m ssag .
`Th cli nt tim s out and
`retransmits the DHCPDISCOVER m ssag if th cli nt r c iv s no
`DHCPOFFER messages.
`
`4. The servers receive the DHCPREQUEST broadcast from the client.
`Those servers not selected by the DHCPREQUEST message use the
`message as notification that the client has declined that server's
`offer.
`The server selected in the DHCPREQUEST message commits the
`binding for the client to persistent storage and responds with a
`DHCPACK message containing the configuration parameters for the
`requesting client.
`The combination of 'chaddr' and assigned
`network address constitute an unique identifier for the client's
`lease and are used by both the client and server to identify a
`lease referred to in any DHCP messages.
`The 'yiaddr' field in the
`DHCPACK messages is filled in with the selected network address.
`
`If the selected server is unable to satisfy the DHCPREQUEST message
`(e.g.,
`the requested network address has been allocated),
`the
`server SHOULD respond with a DHCPNAK message.
`
`A server may choose to mark addresses offered to clients in
`DHCPOFFER messages as unavailable.
`The server should mark an
`address offered to a client in a DHCPOFFER message as available if
`the server receives no DHCPREQUEST message from that client.
`
`fi1e:///C :/Users/25474/AppData/Loca1/Temp/Low/GHKZIR3J.htm
`
`12/ 17/2013
`
`Page 12 of 37
`
`

`
`Page 13 of37
`
`Droms
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`OCTE
`
`TS
`
`DESCRIPTION
`
`[Page 13]
`
`October 1993
`
`htype
`
`hlen
`
`hops
`
`Xid
`
`secs
`
`flags
`ciaddr
`
`yiaddr
`siaddr
`
`giaddr
`
`chaddr
`sname
`file
`
`options
`
`l\J
`
`16
`64
`128
`
`312
`
`Message op code / message type.
`1 : BOOTREQUEST,
`2 : BOOTREPLY
`Hardwar
`addr ss typ ,
`s
`ARP s ction 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.
`
`cli nt
`
`laps d sinc
`
`s conds
`Filled in by cli nt,
`started trying to boot.
`Flags (see figure 2).
`Client IP address; filled in by client in
`DHCPREQUEST if verifying 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.
`
`Relay agent IP address, used in booting via a
`relay—agent.
`Client hardware address.
`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 DHC?OFFER.
`Optional parameters field.
`See the options
`documents for a list of defined options.
`
`Table
`
`1:
`
`Description of fields in a DHCP message
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/G}H(ZIR3J.htm
`
`12/17/2013
`
`Page 13 of 37
`
`

`
`Page 14 of 37
`
`[Page 14]
`
`October 1993
`
`Droms
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`Server
`(not selected)
`
`Client
`
`V
`
`V
`
`Server
`(selected)
`
`V
`
`Begins initialization
`
`/ DHCPDISCOVER
`
`DHCPDISCOVER \
`
`/
`
`\
`
`Determines
`configuration
`
`Determines
`configuration
`
`\
`
`\
`
`/DHCPOFFER
`
`/
`
`DHCPOFFER\
`
`/
`
`\
`Collects replies
`\
`Selects configuration
`
`/ DHCPREQUEST
`
`DHCPREQUEST \
`
`/
`
`\
`
`Commits configuration
`
`/ DHCPACK
`
`/
`
`Initialization complete
`
`Graceful shutdown
`
`\
`
`V
`
`DHCPRELEASE \
`
`Discards lease
`
`V
`
`V
`
`xchang d b tw
`Figure 3: Timeline diagram of m ssag s
`client and servers when allocating a new network address
`
`n DHCP
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/G}H(ZIR3J.htm
`
`12/17/2013
`
`Page 14 of 37
`
`

`
`Page 15 of37
`
`Droms
`
`RFC 1541
`
`Dynamic Host Configuration Protocol
`
`[Page 15]
`
`October 1993
`
`Message
`
`Use
`
`D{C?D1SCOVER — Client broadcas: to locate available servers.
`
`D{C?OFFER
`
`— Server to clien:
`in response to DHCPDISCOVER with
`offer of configuration parameters.
`
`D{C?REQUEST
`
`— Client broadcas: to servers requesting offered
`parameters from
`one server and implicitly declining
`offers from all others.
`
`D{C?ACK
`
`D{C?NAK
`
`— Server to clien: with configuration parameters,
`including commi:ted network address.
`
`— Server to clien
`: refusing request for configuration
`param t rs (
`.g., r qu st d n
`twork address already
`allocated).
`
`DHCPDTCLINT
`
`— Client to server indicating configuration parameters
`(e.g., network address)
`invalid.
`
`DHCPRTLFAST
`
`—
`
`Client to server relinquishing network address and
`cancelling remaining lease.
`
`S :
`
`Table 2:
`
`DHCP message
`
`h configuration
`5. The client receives the DHCPACK message wi
`neck on the parameters
`parameters.
`The client performs a final c
`and notes the duration
`(e.g., ARP for allocated network address),
`of the lease and the lease identification cookie specified in the
`DHCPACK message. At this point,
`the clien : is configured.
`If the
`client detects a problem with the parameters in the DHCPACK
`ssage to the s