`
`>
`
`Network Working Group R. Droms
`Request for Comments: 1541 Bucknell University
`Obsoletes: 1531 October 1993
`Category: Standards Track
`
`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
`The Dynamic Host Configuration Protocol (DHCP) provides a framework
`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
`1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
`1.1 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
`1.2 Problem definition and issues . . . . . . . . . . . . . . . . 4
`1.3 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
`1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
`1.5 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
`2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 8
`2.1 Configuration parameters repository . . . . . . . . . . . . . 10
`2.2 Dynamic allocation of network addresses . . . . . . . . . . . 11
`3. The Client-Server Protocol . . . . . . . . . . . . . . . . . . 11
`3.1 Client-server interaction - allocating a network address. . . 12
`3.2 Client-server interaction - reusing a previously allocated
`network address . . . . . . . . . . . . . . . . . . . . . . . 17
`3.3 Interpretation and representation of time values. . . . . . . 19
`3.4 Host parameters in DHCP . . . . . . . . . . . . . . . . . . . 19
`3.5 Use of DHCP in clients with multiple interfaces . . . . . . . 20
`3.6 When clients should use DHCP. . . . . . . . . . . . . . . . . 20
`4. Specification of the DHCP client-server protocol . . . . . . . 21
`
`Droms [Page 1]
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 1 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`Page 2 of 37
`
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
`4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 21
`4.2 DHCP server administrative controls . . . . . . . . . . . . . 23
`4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 24
`4.3.1 DHCPDISCOVER message. . . . . . . . . . . . . . . . . . . . 24
`4.3.2 DHCPREQUEST message . . . . . . . . . . . . . . . . . . . . 27
`4.3.3 DHCPDECLINE message . . . . . . . . . . . . . . . . . . . . 29
`4.3.4 DHCPRELEASE message . . . . . . . . . . . . . . . . . . . . 29
`4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 29
`4.4.1 Initialization and allocation of network address. . . . . . 29
`4.4.2 Initialization with known network address . . . . . . . . . 33
`4.4.3 Initialization with a known DHCP server address . . . . . . 34
`4.4.4 Reacquisition and expiration. . . . . . . . . . . . . . . . 34
`4.4.5 DHCPRELEASE . . . . . . . . . . . . . . . . . . . . . . . . 35
`5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 35
`6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
`7. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
`8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 38
`A. Host Configuration Parameters . . . . . . . . . . . . . . . . 39
`List of Figures
`1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
`2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 10
`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
`List of Tables
`1. Description of fields in a DHCP message. . . . . . . . . . . . 14
`2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 16
`3. Fields and options used by DHCP servers. . . . . . . . . . . . 25
`4. Fields and options used by DHCP clients. . . . . . . . . . . . 32
`1. Introduction
`The Dynamic Host Configuration Protocol (DHCP) provides configuration
`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 client-server model, where designated DHCP server
`hosts allocate network addresses and deliver configuration parameters
`to dynamically configured hosts. Throughout the remainder of this
`document, the term "server" refers 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
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 2 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`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
`protocol implementations in the Internet would preclude reliable
`operation if random hosts were allowed to respond to DHCP requests.
`For example, IP requires the setting of many parameters within the
`protocol 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,
`distributed address allocation schemes depend on a polling/defense
`mechanism for discovery of addresses that are already in use. IP
`hosts may not always be able to defend their network addresses, so
`that such a distributed address allocation scheme cannot be
`guaranteed to avoid allocation of duplicate network addresses.
`DHCP supports three mechanisms for IP address allocation. In
`"automatic allocation", DHCP assigns a permanent IP address to a
`host. 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
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 3 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`Page 4 of 37
`
`extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
`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.
`In other related work, the path minimum transmission unit (MTU)
`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
`location and selection [6]. Finally, the Host Requirements RFCs [3,
`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 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]
`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].
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 4 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`Page 5 of 37
`
`DHCP is not intended for use in configuring routers.
`1.3 Requirements
`Throughout this document, the words that are used to define the
`significance of particular requirements are capitalized. These words
`are:
`o "MUST"
`This word or the adjective "REQUIRED" means that the
`item is an absolute requirement of this specification.
`o "MUST NOT"
`This phrase means that the item is an absolute prohibition
`of this specification.
`o "SHOULD"
`This word or the adjective "RECOMMENDED" means that there
`may exist valid reasons in particular circumstances to ignore
`this item, but the full implications should be understood and
`the case carefully weighed before choosing a different course.
`o "SHOULD NOT"
`This phrase 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 [Page 5]
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
`o "MAY"
`This word or the adjective "OPTIONAL" means that this item is
`truly optional. One vendor may choose to include the item
`because a particular marketplace requires it or because it
`enhances the product, for example; another vendor may omit the
`same item.
`1.4 Terminology
`This document uses the following terms:
`o "DHCP client"
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 5 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`Page 6 of 37
`
`A DHCP client is an Internet host using DHCP to obtain
`configuration parameters such as a network address.
`o "DHCP server"
`A DHCP server is an Internet host that returns configuration
`parameters to DHCP clients.
`o "BOOTP relay agent"
`A BOOTP relay agent is an Internet host or router that passes
`DHCP messages between DHCP clients and DHCP servers. DHCP is
`designed to use the same relay agent behavior as specified in
`the BOOTP protocol specification.
`o "binding"
`A binding is a collection of configuration parameters, including
`at least an IP address, associated with or "bound to" a DHCP
`client. Bindings are managed by DHCP servers.
`1.5 Design goals
`The following list gives general design goals for DHCP.
`o DHCP should be a mechanism rather than a policy. DHCP must
`allow local system administrators control over configuration
`parameters where desired; e.g., local system administrators
`should be able to enforce local policies concerning allocation
`and access to local resources where desired.
`
`Droms [Page 6]
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
`o Hosts should require no manual configuration. Each host should
`be able to discover appropriate local configuration parameters
`without user intervention and incorporate those parameters into
`its own configuration.
`o Networks should require no hand configuration for individual
`hosts. Under normal circumstances, the network manager should
`not have to enter any per-host configuration parameters.
`o DHCP should not require a server on each subnet. To allow for
`scale and economy, DHCP must work across routers or through the
`intervention of BOOTP/DHCP relay agents.
`o A DHCP host must be prepared to receive multiple responses to a
`request for configuration parameters. Some installations may
`include multiple, overlapping DHCP servers to enhance
`reliability and increase performance.
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 6 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`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,
`o Retain host configuration across host reboot. A host should,
`whenever possible, be assigned the same configuration parameters
`(e.g., network address) in response to each request,
`o Retain host configuration across server reboots, and, whenever
`possible, a host should be assigned the same configuration
`parameters despite restarts of the DHCP mechanism,
`o Allow automatic assignment of configuration parameters to new
`hosts to avoid hand configuration for new hosts,
`o Support fixed or permanent allocation of configuration
`parameters to specific hosts.
`
`Droms [Page 7]
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
`2. Protocol Summary
`From the client's point of view, DHCP is an extension of the BOOTP
`mechanism. This behavior allows existing BOOTP clients to
`interoperate with DHCP servers without requiring any change to the
`clients' initialization software. A separate document details the
`interactions between BOOTP and DHCP clients and servers [9]. There
`are some new, optional transactions that optimize the interaction
`between DHCP clients and servers that are described in sections 3 and
`4.
`Figure 1 gives the format of a DHCP message and table 1 describes
`each of the fields in the DHCP message. The numbers in parentheses
`indicate the size of each field in octets. The names for the fields
`given in the figure will be used throughout this document to refer to
`the fields in DHCP messages.
`There are two primary differences between DHCP and BOOTP. First,
`DHCP defines mechanisms through which clients can be assigned a
`network address for a fixed lease, allowing for serial reassignment
`of network addresses to different clients. Second, DHCP provides the
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 7 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`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 defines a new 'client identifier' option that is used to pass an
`explicit client identifier to a DHCP server. This change eliminates
`the overloading of the 'chaddr' field in BOOTP messages, where
`'chaddr' is used both as a hardware address for transmission of BOOTP
`reply messages and as a client identifier. The 'client identifier'
`option may contain a hardware address, identical to the contents of
`the 'chaddr' field, or it may contain another type of identifier,
`such as a DNS name. Other client identifier types may be defined as
`needed for use with DHCP. New client identifier types will be
`registered with the IANA [18] and will be included in new revisions
`of the Assigned Numbers document, as well as described in detail in
`future revisions of the DHCP Options [2].
`
`Droms [Page 8]
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
`0 1 2 3
`0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`| op (1) | htype (1) | hlen (1) | hops (1) |
`+---------------+---------------+---------------+---------------+
`| xid (4) |
`+-------------------------------+-------------------------------+
`| secs (2) | flags (2) |
`+-------------------------------+-------------------------------+
`| ciaddr (4) |
`+---------------------------------------------------------------+
`| yiaddr (4) |
`+---------------------------------------------------------------+
`| siaddr (4) |
`+---------------------------------------------------------------+
`| giaddr (4) |
`+---------------------------------------------------------------+
`| |
`| chaddr (16) |
`| |
`| |
`+---------------------------------------------------------------+
`| |
`| sname (64) |
`+---------------------------------------------------------------+
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 8 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`Page 9 of 37
`
`| |
`| file (128) |
`+---------------------------------------------------------------+
`| |
`| options (312) |
`+---------------------------------------------------------------+
`Figure 1: Format of a DHCP message
`DHCP clarifies the interpretation of the 'siaddr' field as the
`address of the server to use in the next step of the client's
`bootstrap process. A DHCP server may return its own address in the
`'siaddr' field, if the server is prepared to supply the next
`bootstrap service (e.g., delivery of an operating system executable
`image). A DHCP server always returns its own address in the 'server
`identifier' option.
`The options field is now variable length, with the minimum extended
`to 312 octets. This brings the minimum size of a DHCP message up to
`576 octets, the minimum IP datagram size a host must be prepared to
`accept [3]. DHCP clients may negotiate the use of larger DHCP
`messages through the 'Maximum DHCP message size' option. The options
`field may be further extended into the 'file' and 'sname' fields.
`
`Droms [Page 9]
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
`A new option, called 'vendor specific information', has been added to
`allow for expansion of the number of options that can be supported
`[2]. Options encapsulated as 'vendor specific information' must be
`carefully defined and documented so as to allow for interoperability
`between clients and servers from diferent vendors. In particular,
`vendors defining 'vendor specific information' MUST document those
`options in the form of the DHCP Options document, MUST choose to
`represent those options either in data types already defined for DHCP
`options or in other well-defined data types, and MUST choose options
`that can be readily encoded in configuration files for exchange with
`servers provided by other vendors. Options included as 'vendor
`specific options' MUST be readily supportable by all servers.
`1 1 1 1 1 1
`0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`B| MBZ |
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`B: BROADCAST flag
`MBZ: MUST BE ZERO (reserved for future use)
`Figure 2: Format of the 'flags' field
`DHCP uses the 'flags' field [21]. The leftmost bit is defined as the
`BROADCAST (B) flag. The semantics of this flag are discussed in
`section 4.1 of this document. The remaining bits of the flags field
`are reserved for future use. They MUST be set to zero by clients and
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 9 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`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 service stores a key-value entry
`for each client, where the key is some unique identifier (for
`example, an IP subnet number and a unique identifier within the
`subnet) and the value contains the configuration parameters for the
`client.
`For example, the key might be the pair (IP-subnet-number, hardware-
`address), allowing for serial or concurrent reuse of a hardware
`address on different subnets, and for hardware addresses that may not
`be globally unique. Alternately, the key might be the pair (IP-
`subnet-number, hostname), allowing the server to assign parameters
`intelligently to a host that has been moved to a different subnet or
`
`Droms [Page 10]
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
`has changed hardware addresses (perhaps because the network interface
`failed and was replaced).
`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
`issue a message to release the address 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
`lease has expired. The server should use whatever information is
`available in the configuration information repository to choose an
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 10 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`Page 11 of 37
`
`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 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
`
`is the same magic cookie as is defined in RFC 1497). The remainder
`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 separate document gives the complete set 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 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
`typical client-server interaction. If the client already knows its
`address, some steps may be omitted; this abbreviated interaction is
`described in section 3.2.
`1. 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
`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
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 11 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`Page 12 of 37
`
`network address to another client. The server unicasts the
`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
`
`DHCPREQUEST message that MUST include the 'server identifier'
`option to indicate which server it has selected, and may include
`other options specifying desired configuration values. This
`DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP
`relay agents. To help ensure that any DHCP/BOOTP relay agents
`forward the 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 message. The client times out and
`retransmits the DHCPDISCOVER message if the client receives 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.
`
`file:///C:/Users/25474/AppData/Local/Temp/Low/GHKZIR3J.htm
`
`12/17/2013
`
`Page 12 of 37
`
`Cisco -- Exhibit 1013
`
`
`
`Page 13 of 37
`
`Droms [Page 13]
`RFC 1541 Dynamic Host Configuration Protocol October 1993
`
`FIELD OCTETS DESCRIPTION
`-----
`------
`-----------
`op 1 Message