< draft-ietf-dhc-dhcp-07.txt   draft-ietf-dhc-dhcp-08.txt >
Network Working Group R. Droms Network Working Group R. Droms
INTERNET DRAFT Bucknell University INTERNET DRAFT Bucknell University
Obsoletes: draft-ietf-dhc-dhcp-06.txt May 1996 Obsoletes: draft-ietf-dhc-dhcp-07.txt November 1996
Expires November 1996 Expires May 1997
Dynamic Host Configuration Protocol Dynamic Host Configuration Protocol
<draft-ietf-dhc-dhcp-07.txt> <draft-ietf-dhc-dhcp-08.txt>
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 4 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 4
1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Problem definition and issues . . . . . . . . . . . . . . . . 5 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 5
1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
DRAFT Dynamic Host Configuration Protocol November 1996
2.1 Configuration parameters repository . . . . . . . . . . . . . 11 2.1 Configuration parameters repository . . . . . . . . . . . . . 11
2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12 2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13 3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
3.1 Client-server interaction - allocating a network address. . . 13 3.1 Client-server interaction - allocating a network address. . . 13
3.2 Client-server interaction - reusing a previously allocated 3.2 Client-server interaction - reusing a previously allocated
network address . . . . . . . . . . . . . . . . . . . . . . . 17 network address . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Interpretation and representation of time values. . . . . . . 20 3.3 Interpretation and representation of time values. . . . . . . 20
3.4 Obtaining parameters with externally configured network 3.4 Obtaining parameters with externally configured network
address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 20 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 20
3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22 3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
4. Specification of the DHCP client-server protocol. . . . . . . 22 4. Specification of the DHCP client-server protocol. . . . . . . 22
4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22 4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
4.2 DHCP server administrative controls . . . . . . . . . . . . . 25 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 33 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 33
5. References . . . . . . . . . . . . . . . . . . . . . . . . . .40 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .40
6. Security Considerations. . . . . . . . . . . . . . . . . . . .42 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .41
7. Author's Address . . . . . . . . . . . . . . . . . . . . . . .42 7. Security Considerations. . . . . . . . . . . . . . . . . . . .42
A. Host Configuration Parameters . . . . . . . . . . . . . . . .43 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .43
A. Host Configuration Parameters . . . . . . . . . . . . . . . .44
List of Figures List of Figures
1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9 1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11 2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
3. Timeline diagram of messages exchanged between DHCP client and 3. Timeline diagram of messages exchanged between DHCP client and
servers when allocating a new network address. . . . . . . . . 15 servers when allocating a new network address. . . . . . . . . 15
4. Timeline diagram of messages exchanged between DHCP client and 4. Timeline diagram of messages exchanged between DHCP client and
servers when reusing a previously allocated network address. . 18 servers when reusing a previously allocated network address. . 18
5. State-transition diagram for DHCP clients. . . . . . . . . . . 34 5. State-transition diagram for DHCP clients. . . . . . . . . . . 34
skipping to change at page 3, line 5 skipping to change at page 3, line 5
5. Fields and options used by DHCP clients. . . . . . . . . . . . 37 5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol (DHCP) provides configuration The Dynamic Host Configuration Protocol (DHCP) provides configuration
parameters to Internet hosts. DHCP consists of two components: a parameters to Internet hosts. DHCP consists of two components: a
protocol for delivering host-specific configuration parameters from a protocol for delivering host-specific configuration parameters from a
DHCP server to a host and a mechanism for allocation of network DHCP server to a host and a mechanism for allocation of network
addresses to hosts. addresses to hosts.
DRAFT Dynamic Host Configuration Protocol November 1996
DHCP is built on a client-server model, where designated DHCP server DHCP is built on a client-server model, where designated DHCP server
hosts allocate network addresses and deliver configuration parameters hosts allocate network addresses and deliver configuration parameters
to dynamically configured hosts. Throughout the remainder of this to dynamically configured hosts. Throughout the remainder of this
document, the term "server" refers to a host providing initialization document, the term "server" refers to a host providing initialization
parameters through DHCP, and the term "client" refers to a host parameters through DHCP, and the term "client" refers to a host
requesting initialization parameters from a DHCP server. requesting initialization parameters from a DHCP server.
A host should not act as a DHCP server unless explicitly configured A host should not act as a DHCP server unless explicitly configured
to do so by a system administrator. The diversity of hardware and to do so by a system administrator. The diversity of hardware and
protocol implementations in the Internet would preclude reliable protocol implementations in the Internet would preclude reliable
skipping to change at page 4, line 4 skipping to change at page 4, line 4
for assigning an IP address to a new client being permanently for assigning an IP address to a new client being permanently
connected to a network where IP addresses are sufficiently scarce connected to a network where IP addresses are sufficiently scarce
that it is important to reclaim them when old clients are retired. that it is important to reclaim them when old clients are retired.
Manual allocation allows DHCP to be used to eliminate the error-prone Manual allocation allows DHCP to be used to eliminate the error-prone
process of manually configuring hosts with IP addresses in process of manually configuring hosts with IP addresses in
environments where (for whatever reasons) it is desirable to manage environments where (for whatever reasons) it is desirable to manage
IP address assignment outside of the DHCP mechanisms. IP address assignment outside of the DHCP mechanisms.
The format of DHCP messages is based on the format of BOOTP messages, 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 to capture the BOOTP relay agent behavior described as part of the
DRAFT Dynamic Host Configuration Protocol November 1996
BOOTP specification [7, 21] and to allow interoperability of existing BOOTP specification [7, 21] and to allow interoperability of existing
BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
the necessity of having a DHCP server on each physical network the necessity of having a DHCP server on each physical network
segment. segment.
1.1 Changes to RFC 1541 1.1 Changes to RFC 1541
This document updates the DHCP protocol specification that appears in This document updates the DHCP protocol specification that appears in
RFC1541. A new DHCP message type, DHCPINFORM, has been added; see RFC1541. A new DHCP message type, DHCPINFORM, has been added; see
section 3.4, 4.3 and 4.4 for details. The classing mechanism for section 3.4, 4.3 and 4.4 for details. The classing mechanism for
identifying DHCP clients to DHCP servers has been extended to include identifying DHCP clients to DHCP servers has been extended to include
"vendor" and "user" classes as defined in sections 4.2 and 4.3. The "vendor" classes as defined in sections 4.2 and 4.3. The minimum
minimum lease time restriction has been removed. Finally, many lease time restriction has been removed. Finally, many editorial
editorial changes have been made to clarify the text as a result of changes have been made to clarify the text as a result of experience
experience gained in DHCP interoperability tests. gained in DHCP interoperability tests.
1.2 Related Work 1.2 Related Work
There are several Internet protocols and related mechanisms that There are several Internet protocols and related mechanisms that
address some parts of the dynamic host configuration problem. The address some parts of the dynamic host configuration problem. The
Reverse Address Resolution Protocol (RARP) [10] (through the Reverse Address Resolution Protocol (RARP) [10] (through the
extensions defined in the Dynamic RARP (DRARP) [5]) explicitly extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
addresses the problem of network address discovery, and includes an addresses the problem of network address discovery, and includes an
automatic IP address assignment mechanism. The Trivial File Transfer automatic IP address assignment mechanism. The Trivial File Transfer
Protocol (TFTP) [20] provides for transport of a boot image from a Protocol (TFTP) [20] provides for transport of a boot image from a
skipping to change at page 5, line 4 skipping to change at page 5, line 4
[19]. The Resource Location Protocol RLP [1] provides for location [19]. The Resource Location Protocol RLP [1] provides for location
of higher level services. Sun Microsystems diskless workstations use of higher level services. Sun Microsystems diskless workstations use
a boot procedure that employs RARP, TFTP and an RPC mechanism called a boot procedure that employs RARP, TFTP and an RPC mechanism called
"bootparams" to deliver configuration information and operating "bootparams" to deliver configuration information and operating
system code to diskless hosts. (Sun Microsystems, Sun Workstation system code to diskless hosts. (Sun Microsystems, Sun Workstation
and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun
networks also use DRARP and an auto-installation mechanism to networks also use DRARP and an auto-installation mechanism to
automate the configuration of new hosts in an existing network. automate the configuration of new hosts in an existing network.
In other related work, the path minimum transmission unit (MTU) In other related work, the path minimum transmission unit (MTU)
DRAFT Dynamic Host Configuration Protocol November 1996
discovery algorithm can determine the MTU of an arbitrary internet discovery algorithm can determine the MTU of an arbitrary internet
path [14]. The Address Resolution Protocol (ARP) has been proposed path [14]. The Address Resolution Protocol (ARP) has been proposed
as a transport protocol for resource location and selection [6]. as a transport protocol for resource location and selection [6].
Finally, the Host Requirements RFCs [3, 4] mention specific Finally, the Host Requirements RFCs [3, 4] mention specific
requirements for host reconfiguration and suggest a scenario for requirements for host reconfiguration and suggest a scenario for
initial configuration of diskless hosts. initial configuration of diskless hosts.
1.3 Problem definition and issues 1.3 Problem definition and issues
DHCP is designed to supply DHCP clients with the configuration DHCP is designed to supply DHCP clients with the configuration
skipping to change at page 6, line 5 skipping to change at page 6, line 5
o "MUST" o "MUST"
This word or the adjective "REQUIRED" means that the This word or the adjective "REQUIRED" means that the
item is an absolute requirement of this specification. item is an absolute requirement of this specification.
o "MUST NOT" o "MUST NOT"
This phrase means that the item is an absolute prohibition This phrase means that the item is an absolute prohibition
of this specification. of this specification.
DRAFT Dynamic Host Configuration Protocol November 1996
o "SHOULD" o "SHOULD"
This word or the adjective "RECOMMENDED" means that there This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to ignore may exist valid reasons in particular circumstances to ignore
this item, but the full implications should be understood and this item, but the full implications should be understood and
the case carefully weighed before choosing a different course. the case carefully weighed before choosing a different course.
o "SHOULD NOT" o "SHOULD NOT"
This phrase means that there may exist valid reasons in This phrase means that there may exist valid reasons in
skipping to change at page 7, line 5 skipping to change at page 7, line 5
A DHCP server is an Internet host that returns configuration A DHCP server is an Internet host that returns configuration
parameters to DHCP clients. parameters to DHCP clients.
o "BOOTP relay agent" o "BOOTP relay agent"
A BOOTP relay agent or relay agent is an Internet host or router that A BOOTP relay agent or relay agent is an Internet host or router that
passes DHCP messages between DHCP clients and DHCP servers. DHCP is passes DHCP messages between DHCP clients and DHCP servers. DHCP is
designed to use the same relay agent behavior as specified in designed to use the same relay agent behavior as specified in
the BOOTP protocol specification. the BOOTP protocol specification.
DRAFT Dynamic Host Configuration Protocol November 1996
o "binding" o "binding"
A binding is a collection of configuration parameters, including A binding is a collection of configuration parameters, including
at least an IP address, associated with or "bound to" a DHCP at least an IP address, associated with or "bound to" a DHCP
client. Bindings are managed by DHCP servers. client. Bindings are managed by DHCP servers.
1.6 Design goals 1.6 Design goals
The following list gives general design goals for DHCP. The following list gives general design goals for DHCP.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
hosts and with existing network protocol implementations. hosts and with existing network protocol implementations.
o DHCP must interoperate with the BOOTP relay agent behavior as o DHCP must interoperate with the BOOTP relay agent behavior as
described by RFC 951 and by RFC 1542 [21]. described by RFC 951 and by RFC 1542 [21].
o DHCP must provide service to existing BOOTP clients. o DHCP must provide service to existing BOOTP clients.
The following list gives design goals specific to the transmission of The following list gives design goals specific to the transmission of
the network layer parameters. DHCP must: the network layer parameters. DHCP must:
DRAFT Dynamic Host Configuration Protocol November 1996
o Guarantee that any specific network address will not be in o Guarantee that any specific network address will not be in
use by more than one DHCP client at a time, use by more than one DHCP client at a time,
o Retain DHCP client configuration across DHCP client reboot. A DHCP o Retain DHCP client configuration across DHCP client reboot. A DHCP
client should, whenever possible, be assigned the same configuration client should, whenever possible, be assigned the same configuration
parameters (e.g., network address) in response to each request, parameters (e.g., network address) in response to each request,
o Retain DHCP client configuration across server reboots, and, whenever o Retain DHCP client configuration across server reboots, and, whenever
possible, a DHCP client should be assigned the same configuration possible, a DHCP client should be assigned the same configuration
parameters despite restarts of the DHCP mechanism, parameters despite restarts of the DHCP mechanism,
skipping to change at page 9, line 4 skipping to change at page 9, line 4
of network addresses to different clients. Second, DHCP provides the of network addresses to different clients. Second, DHCP provides the
mechanism for a client to acquire all of the IP configuration mechanism for a client to acquire all of the IP configuration
parameters that it needs in order to operate. parameters that it needs in order to operate.
DHCP introduces a small change in terminology intended to clarify the DHCP introduces a small change in terminology intended to clarify the
meaning of one of the fields. What was the "vendor extensions" field meaning of one of the fields. What was the "vendor extensions" field
in BOOTP has been re-named the "options" field in DHCP. Similarly, in BOOTP has been re-named the "options" field in DHCP. Similarly,
the tagged data items that were used inside the BOOTP "vendor the tagged data items that were used inside the BOOTP "vendor
extensions" field, which were formerly referred to as "vendor extensions" field, which were formerly referred to as "vendor
extensions," are now termed simply "options." extensions," are now termed simply "options."
DRAFT Dynamic Host Configuration Protocol November 1996
0 1 2 3 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 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) | | op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| xid (4) | | xid (4) |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| secs (2) | flags (2) | | secs (2) | flags (2) |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| ciaddr (4) | | ciaddr (4) |
skipping to change at page 10, line 5 skipping to change at page 10, line 5
reply messages and as a client identifier. The 'client identifier' reply messages and as a client identifier. The 'client identifier'
is an opaque key, not to be interpreted by the server; for example, is an opaque key, not to be interpreted by the server; for example,
the 'client identifier' may contain a hardware address, identical to the 'client identifier' may contain a hardware address, identical to
the contents of the 'chaddr' field, or it may contain another type of the contents of the 'chaddr' field, or it may contain another type of
identifier, such as a DNS name. The 'client identifier' chosen by a identifier, such as a DNS name. The 'client identifier' chosen by a
DHCP client MUST be unique to that client within the subnet to which DHCP client MUST be unique to that client within the subnet to which
the client is attached. If the client uses a 'client identifier' in the client is attached. If the client uses a 'client identifier' in
one message, it MUST use that same identifier in all subsequent one message, it MUST use that same identifier in all subsequent
messages, to ensure that all servers correctly identify the client. messages, to ensure that all servers correctly identify the client.
DRAFT Dynamic Host Configuration Protocol November 1996
DHCP clarifies the interpretation of the 'siaddr' field as the DHCP clarifies the interpretation of the 'siaddr' field as the
address of the server to use in the next step of the client's 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 bootstrap process. A DHCP server may return its own address in the
'siaddr' field, if the server is prepared to supply the next 'siaddr' field, if the server is prepared to supply the next
bootstrap service (e.g., delivery of an operating system executable bootstrap service (e.g., delivery of an operating system executable
image). A DHCP server always returns its own address in the 'server image). A DHCP server always returns its own address in the 'server
identifier' option. identifier' option.
FIELD OCTETS DESCRIPTION FIELD OCTETS DESCRIPTION
----- ------ ----------- ----- ------ -----------
skipping to change at page 11, line 4 skipping to change at page 11, line 4
directory-path name in DHCPOFFER. directory-path name in DHCPOFFER.
options var Optional parameters field. See the options options var Optional parameters field. See the options
documents for a list of defined options. documents for a list of defined options.
Table 1: Description of fields in a DHCP message Table 1: Description of fields in a DHCP message
The 'options' field is now variable length. A DHCP client must be The 'options' field is now variable length. A DHCP client must be
prepared to receive DHCP messages with an 'options' field of at least prepared to receive DHCP messages with an 'options' field of at least
length 312 octets. This requirement implies that a DHCP client must length 312 octets. This requirement implies that a DHCP client must
be prepared to receive a message of up to 576 octets, the minimum IP be prepared to receive a message of up to 576 octets, the minimum IP
DRAFT Dynamic Host Configuration Protocol November 1996
datagram size an IP host must be prepared to accept [3]. DHCP datagram size an IP host must be prepared to accept [3]. DHCP
clients may negotiate the use of larger DHCP messages through the clients may negotiate the use of larger DHCP messages through the
'maximum DHCP message size' option. The options field may be further 'maximum DHCP message size' option. The options field may be further
extended into the 'file' and 'sname' fields. extended into the 'file' and 'sname' fields.
In the case of a client using DHCP for initial configuration (before In the case of a client using DHCP for initial configuration (before
the client's TCP/IP software has been completely configured), DHCP the client's TCP/IP software has been completely configured), DHCP
requires creative use of the client's TCP/IP software and liberal requires creative use of the client's TCP/IP software and liberal
interpretation of RFC 1122. The TCP/IP software SHOULD accept and interpretation of RFC 1122. The TCP/IP software SHOULD accept and
forward to the IP layer any IP packets delivered to the client's forward to the IP layer any IP packets delivered to the client's
skipping to change at page 12, line 5 skipping to change at page 12, line 5
2.1 Configuration parameters repository 2.1 Configuration parameters repository
The first service provided by DHCP is to provide persistent storage The first service provided by DHCP is to provide persistent storage
of network parameters for network clients. The model of DHCP of network parameters for network clients. The model of DHCP
persistent storage is that the DHCP service stores a key-value entry persistent storage is that the DHCP service stores a key-value entry
for each client, where the key is some unique identifier (for for each client, where the key is some unique identifier (for
example, an IP subnet number and a unique identifier within the example, an IP subnet number and a unique identifier within the
subnet) and the value contains the configuration parameters for the subnet) and the value contains the configuration parameters for the
client. client.
DRAFT Dynamic Host Configuration Protocol November 1996
For example, the key might be the pair (IP-subnet-number, hardware- For example, the key might be the pair (IP-subnet-number, hardware-
address) (note that the "hardware-address" should be typed by the address) (note that the "hardware-address" should be typed by the
type of hardware to accommodate possible duplication of hardware type of hardware to accommodate possible duplication of hardware
addresses resulting from bit-ordering problems in a mixed-media, addresses resulting from bit-ordering problems in a mixed-media,
bridged network) allowing for serial or concurrent reuse of a bridged network) allowing for serial or concurrent reuse of a
hardware address on different subnets, and for hardware addresses hardware address on different subnets, and for hardware addresses
that may not be globally unique. Alternately, the key might be the that may not be globally unique. Alternately, the key might be the
pair (IP-subnet-number, hostname), allowing the server to assign pair (IP-subnet-number, hostname), allowing the server to assign
parameters intelligently to a DHCP client that has been moved to a parameters intelligently to a DHCP client that has been moved to a
different subnet or has changed hardware addresses (perhaps because different subnet or has changed hardware addresses (perhaps because
skipping to change at page 13, line 4 skipping to change at page 13, line 4
the client has been retired. the client has been retired.
In some environments it will be necessary to reassign network In some environments it will be necessary to reassign network
addresses due to exhaustion of available addresses. In such addresses due to exhaustion of available addresses. In such
environments, the allocation mechanism will reuse addresses whose environments, the allocation mechanism will reuse addresses whose
lease has expired. The server should use whatever information is lease has expired. The server should use whatever information is
available in the configuration information repository to choose an available in the configuration information repository to choose an
address to reuse. For example, the server may choose the least address to reuse. For example, the server may choose the least
recently assigned address. As a consistency check, the allocating recently assigned address. As a consistency check, the allocating
server SHOULD probe the reused address before allocating the address, server SHOULD probe the reused address before allocating the address,
DRAFT Dynamic Host Configuration Protocol November 1996
e.g., with an ICMP echo request, and the client SHOULD probe the e.g., with an ICMP echo request, and the client SHOULD probe the
newly received address, e.g., with ARP. newly received address, e.g., with ARP.
3. The Client-Server Protocol 3. The Client-Server Protocol
DHCP uses the BOOTP message format defined in RFC 951 and given in 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 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 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. 'op' field of each DHCP message sent from a server to a client.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
typical client-server interaction. If the client already knows its typical client-server interaction. If the client already knows its
address, some steps may be omitted; this abbreviated interaction is address, some steps may be omitted; this abbreviated interaction is
described in section 3.2. described in section 3.2.
1. The client broadcasts a DHCPDISCOVER message on its local physical 1. The client broadcasts a DHCPDISCOVER message on its local physical
subnet. The DHCPDISCOVER message MAY include options that suggest subnet. The DHCPDISCOVER message MAY include options that suggest
values for the network address and lease duration. BOOTP relay values for the network address and lease duration. BOOTP relay
agents may pass the message on to DHCP servers not on the same agents may pass the message on to DHCP servers not on the same
physical subnet. physical subnet.
DRAFT Dynamic Host Configuration Protocol November 1996
2. Each server may respond with a DHCPOFFER message that includes an 2. Each server may respond with a DHCPOFFER message that includes an
available network address in the 'yiaddr' field (and other available network address in the 'yiaddr' field (and other
configuration parameters in DHCP options). Servers need not configuration parameters in DHCP options). Servers need not
reserve the offered network address, although the protocol will reserve the offered network address, although the protocol will
work more efficiently if the server avoids allocating the offered work more efficiently if the server avoids allocating the offered
network address to another client. When allocating a new address, network address to another client. When allocating a new address,
servers SHOULD check that the offered network address is not servers SHOULD check that the offered network address is not
already in use; e.g., the server may probe the offered address already in use; e.g., the server may probe the offered address
with an ICMP Echo Request. Servers SHOULD be implemented so that with an ICMP Echo Request. Servers SHOULD be implemented so that
network administrators MAY choose to disable probes of newly network administrators MAY choose to disable probes of newly
skipping to change at page 15, line 5 skipping to change at page 15, line 5
DHCPRELEASE - Client to server relinquishing network address and DHCPRELEASE - Client to server relinquishing network address and
cancelling remaining lease. cancelling remaining lease.
DHCPINFORM - Client to server, asking only for local configuration DHCPINFORM - Client to server, asking only for local configuration
parameters; client already has externally configured parameters; client already has externally configured
network address. network address.
Table 2: DHCP messages Table 2: DHCP messages
DRAFT Dynamic Host Configuration Protocol November 1996
Server Client Server Server Client Server
(not selected) (selected) (not selected) (selected)
v v v v v v
| | | | | |
| Begins initialization | | Begins initialization |
| | | | | |
| _____________/|\_____________ | | _____________/|\_____________ |
|/ DHCPDISCOVER | DHCPDISCOVER \| |/ DHCPDISCOVER | DHCPDISCOVER \|
| | | | | |
skipping to change at page 16, line 5 skipping to change at page 16, line 5
| | | | | |
| |\_____________ | | |\_____________ |
| | DHCPRELEASE \| | | DHCPRELEASE \|
| | | | | |
| | Discards lease | | Discards lease
| | | | | |
v v v v v v
Figure 3: Timeline diagram of messages exchanged between DHCP Figure 3: Timeline diagram of messages exchanged between DHCP
client and servers when allocating a new network address client and servers when allocating a new network address
DRAFT Dynamic Host Configuration Protocol November 1996
3. The client receives one or more DHCPOFFER messages from one or more 3. The client receives one or more DHCPOFFER messages from one or more
servers. The client may choose to wait for multiple responses. servers. The client may choose to wait for multiple responses.
The client chooses one server from which to request configuration The client chooses one server from which to request configuration
parameters, based on the configuration parameters offered in the parameters, based on the configuration parameters offered in the
DHCPOFFER messages. The client broadcasts a DHCPREQUEST message DHCPOFFER messages. The client broadcasts a DHCPREQUEST message
that MUST include the 'server identifier' option to indicate which that MUST include the 'server identifier' option to indicate which
server it has selected, and that MAY include other options server it has selected, and that MAY include other options
specifying desired configuration values. The 'requested IP specifying desired configuration values. The 'requested IP
address' option MUST be set to the value of 'yiaddr' in the address' option MUST be set to the value of 'yiaddr' in the
DHCPOFFER message from the server. This DHCPREQUEST message is DHCPOFFER message from the server. This DHCPREQUEST message is
skipping to change at page 17, line 4 skipping to change at page 17, line 4
A server MAY choose to mark addresses offered to clients in A server MAY choose to mark addresses offered to clients in
DHCPOFFER messages as unavailable. The server SHOULD mark an DHCPOFFER messages as unavailable. The server SHOULD mark an
address offered to a client in a DHCPOFFER message as available if address offered to a client in a DHCPOFFER message as available if
the server receives no DHCPREQUEST message from that client. the server receives no DHCPREQUEST message from that client.
5. The client receives the DHCPACK message with configuration 5. The client receives the DHCPACK message with configuration
parameters. The client SHOULD perform a final check on the parameters. The client SHOULD perform a final check on the
parameters (e.g., ARP for allocated network address), and notes the parameters (e.g., ARP for allocated network address), and notes the
duration of the lease specified in the DHCPACK message. At this duration of the lease specified in the DHCPACK message. At this
DRAFT Dynamic Host Configuration Protocol November 1996
point, the client is configured. If the client detects that the point, the client is configured. If the client detects that the
address is already in use (e.g., through the use of ARP), the address is already in use (e.g., through the use of ARP), the
client MUST send a DHCPDECLINE message to the server and restarts client MUST send a DHCPDECLINE message to the server and restarts
the configuration process. The client SHOULD wait a minimum of ten the configuration process. The client SHOULD wait a minimum of ten
seconds before restarting the configuration process to avoid seconds before restarting the configuration process to avoid
excessive network traffic in case of looping. excessive network traffic in case of looping.
If the client receives a DHCPNAK message, the client restarts the If the client receives a DHCPNAK message, the client restarts the
configuration process. configuration process.
skipping to change at page 18, line 4 skipping to change at page 18, line 4
shows the timing relationships in a typical client-server interaction shows the timing relationships in a typical client-server interaction
for a client reusing a previously allocated network address. for a client reusing a previously allocated network address.
1. The client broadcasts a DHCPREQUEST message on its local subnet. 1. The client broadcasts a DHCPREQUEST message on its local subnet.
The message includes the client's network address in the The message includes the client's network address in the
'requested IP address' option. As the client has not received its 'requested IP address' option. As the client has not received its
network address, it MUST NOT fill in the 'ciaddr' field. BOOTP network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
relay agents pass the message on to DHCP servers not on the same relay agents pass the message on to DHCP servers not on the same
subnet. If the client used a 'client identifier' to obtain its subnet. If the client used a 'client identifier' to obtain its
address, the client MUST use the same 'client identifier' in the address, the client MUST use the same 'client identifier' in the
DRAFT Dynamic Host Configuration Protocol November 1996
DHCPREQUEST message. DHCPREQUEST message.
2. Servers with knowledge of the client's configuration parameters 2. Servers with knowledge of the client's configuration parameters
respond with a DHCPACK message to the client. Servers SHOULD NOT respond with a DHCPACK message to the client. Servers SHOULD NOT
check that the client's network address is already in use; the check that the client's network address is already in use; the
client may respond to ICMP Echo Request messages at this point. client may respond to ICMP Echo Request messages at this point.
If the client's request is invalid (e.g., the client has moved to
a new subnet), servers SHOULD respond with a DHCPNAK message to
the client. Servers SHOULD NOT respond if their information is not
guaranteed to be accurate. For example, a server that identifies
a request for an expired binding that is owned by another server
SHOULD NOT respond with a DHCPNAK unless the servers are using an
explicit mechanism to maintain coherency among the servers.
Server Client Server Server Client Server
v v v v v v
| | | | | |
| Begins | | Begins |
| initialization | | initialization |
| | | | | |
| /|\ | | /|\ |
| ___________/ | \___________ | | ___________/ | \___________ |
| /DHCPREQUEST | DHCPREQUEST\ | | /DHCPREQUEST | DHCPREQUEST\ |
skipping to change at page 19, line 9 skipping to change at page 18, line 49
| DHCPACKS | | DHCPACKS |
| ignored) | | ignored) |
| | | | | |
| | | | | |
v v v v v v
Figure 4: Timeline diagram of messages exchanged between DHCP Figure 4: Timeline diagram of messages exchanged between DHCP
client and servers when reusing a previously allocated client and servers when reusing a previously allocated
network address network address
If the client's request is invalid (e.g., the client has moved
to a new subnet), servers SHOULD respond with a DHCPNAK message to
the client. Servers SHOULD NOT respond if their information is not
guaranteed to be accurate. For example, a server that identifies a
request for an expired binding that is owned by another server SHOULD
DRAFT Dynamic Host Configuration Protocol November 1996
NOT respond with a DHCPNAK unless the servers are using an explicit
mechanism to maintain coherency among the servers.
If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
the same subnet as the server. The server MUST the same subnet as the server. The server MUST
broadcast the DHCPNAK message to the 0xffffffff broadcast address broadcast the DHCPNAK message to the 0xffffffff broadcast address
because the client may not have a correct network address or subnet because the client may not have a correct network address or subnet
mask, and the client may not be answering ARP requests. mask, and the client may not be answering ARP requests.
Otherwise, the server MUST send the DHCPNAK message to the IP Otherwise, the server MUST send the DHCPNAK message to the IP
address of the BOOTP relay agent, as recorded in 'giaddr'. The address of the BOOTP relay agent, as recorded in 'giaddr'. The
relay agent will, in turn, forward the message directly to the relay agent will, in turn, forward the message directly to the
client's hardware address, so that the DHCPNAK can be delivered even client's hardware address, so that the DHCPNAK can be delivered even
if the client has moved to a new network. if the client has moved to a new network.
skipping to change at page 20, line 6 skipping to change at page 20, line 4
algorithm in section 4.1. The client should choose to retransmit algorithm in section 4.1. The client should choose to retransmit
the DHCPREQUEST enough times to give adequate probability of the DHCPREQUEST enough times to give adequate probability of
contacting the server without causing the client (and the user of contacting the server without causing the client (and the user of
that client) to wait overly long before giving up; e.g., a client that client) to wait overly long before giving up; e.g., a client
retransmitting as described in section 4.1 might retransmit the retransmitting as described in section 4.1 might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds, DHCPREQUEST message four times, for a total delay of 60 seconds,
before restarting the initialization procedure. If the client before restarting the initialization procedure. If the client
receives neither a DHCPACK or a DHCPNAK message after employing receives neither a DHCPACK or a DHCPNAK message after employing
the retransmission algorithm, the client MAY choose to use the the retransmission algorithm, the client MAY choose to use the
previously allocated network address and configuration parameters previously allocated network address and configuration parameters
DRAFT Dynamic Host Configuration Protocol November 1996
for the remainder of the unexpired lease. This corresponds to for the remainder of the unexpired lease. This corresponds to
moving to BOUND state in the client state transition diagram shown moving to BOUND state in the client state transition diagram shown
in figure 5. in figure 5.
4. The client may choose to relinquish its lease on a network 4. The client may choose to relinquish its lease on a network
address by sending a DHCPRELEASE message to the server. The address by sending a DHCPRELEASE message to the server. The
client identifies the lease to be released with its client identifies the lease to be released with its
'client identifier', or 'chaddr' and network address in the 'client identifier', or 'chaddr' and network address in the
DHCPRELEASE message. DHCPRELEASE message.
skipping to change at page 21, line 4 skipping to change at page 20, line 53
client than the server commits to its local database of client client than the server commits to its local database of client
information. information.
3.4 Obtaining parameters with externally configured network address 3.4 Obtaining parameters with externally configured network address
If a client has obtained a network address through some other means If a client has obtained a network address through some other means
(e.g., manual configuration), it may use a DHCPINFORM request message (e.g., manual configuration), it may use a DHCPINFORM request message
to obtain other local configuration parameters. Servers receiving a to obtain other local configuration parameters. Servers receiving a
DHCPINFORM message construct a DHCPACK message with any local DHCPINFORM message construct a DHCPACK message with any local
configuration parameters appropriate for the client without: configuration parameters appropriate for the client without:
allocating a new address, checking for an existing binding, filling allocating a new address, checking for an existing binding, filling
in 'yiaddr' or including lease time parameters. The servers SHOULD in 'yiaddr' or including lease time parameters. The servers SHOULD
DRAFT Dynamic Host Configuration Protocol November 1996
unicast the DHCPACK reply to the address given in the 'ciaddr' field unicast the DHCPACK reply to the address given in the 'ciaddr' field
of the DHCPINFORM message. of the DHCPINFORM message.
The server SHOULD check the network address in a DHCPINFORM message The server SHOULD check the network address in a DHCPINFORM message
for consistency, but MUST NOT check for an existing lease. The for consistency, but MUST NOT check for an existing lease. The
server forms a DHCPACK message containing the configuration server forms a DHCPACK message containing the configuration
parameters for the requesting client and sends the DHCPACK message parameters for the requesting client and sends the DHCPACK message
directly to the client. directly to the client.
3.5 Client parameters in DHCP 3.5 Client parameters in DHCP
skipping to change at page 22, line 6 skipping to change at page 22, line 4
the 'requested IP address' option to suggest that a particular IP the 'requested IP address' option to suggest that a particular IP
address be assigned, and may include the 'IP address lease time' address be assigned, and may include the 'IP address lease time'
option to suggest the lease time it would like. Other options option to suggest the lease time it would like. Other options
representing "hints" at configuration parameters are allowed in a representing "hints" at configuration parameters are allowed in a
DHCPDISCOVER or DHCPREQUEST message. However, additional options may DHCPDISCOVER or DHCPREQUEST message. However, additional options may
be ignored by servers, and multiple servers may, therefore, not be ignored by servers, and multiple servers may, therefore, not
return identical values for some options. The 'requested IP address' return identical values for some options. The 'requested IP address'
option is to be filled in only in a DHCPREQUEST message when the option is to be filled in only in a DHCPREQUEST message when the
client is verifying network parameters obtained previously. The client is verifying network parameters obtained previously. The
client fills in the 'ciaddr' field only when correctly configured client fills in the 'ciaddr' field only when correctly configured
DRAFT Dynamic Host Configuration Protocol November 1996
with an IP address in BOUND, RENEWING or REBINDING state. with an IP address in BOUND, RENEWING or REBINDING state.
If a server receives a DHCPREQUEST message with an invalid 'requested If a server receives a DHCPREQUEST message with an invalid 'requested
IP address', the server SHOULD respond to the client with a DHCPNAK IP address', the server SHOULD respond to the client with a DHCPNAK
message and may choose to report the problem to the system message and may choose to report the problem to the system
administrator. The server may include an error message in the administrator. The server may include an error message in the
'message' option. 'message' option.
3.6 Use of DHCP in clients with multiple interfaces 3.6 Use of DHCP in clients with multiple interfaces
skipping to change at page 23, line 6 skipping to change at page 23, line 4
DHCP clients and servers both construct DHCP messages by filling in DHCP clients and servers both construct DHCP messages by filling in
fields in the fixed format section of the message and appending fields in the fixed format section of the message and appending
tagged data items in the variable length option area. The options tagged data items in the variable length option area. The options
area includes first a four-octet 'magic cookie' (which was described area includes first a four-octet 'magic cookie' (which was described
in section 3), followed by the options. The last option must always in section 3), followed by the options. The last option must always
be the 'end' option. be the 'end' option.
DHCP uses UDP as its transport protocol. DHCP messages from a client DHCP uses UDP as its transport protocol. DHCP messages from a client
to a server are sent to the 'DHCP server' port (67), and DHCP to a server are sent to the 'DHCP server' port (67), and DHCP
messages from a server to a client are sent to the 'DHCP client' port messages from a server to a client are sent to the 'DHCP client' port
DRAFT Dynamic Host Configuration Protocol November 1996
(68). A server with multiple network address (e.g., a multi-homed (68). A server with multiple network address (e.g., a multi-homed
host) MAY use any of its network addresses in outgoing DHCP messages. host) MAY use any of its network addresses in outgoing DHCP messages.
DHCP messages broadcast by a client prior to that client obtaining DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header its IP address must have the source address field in the IP header
set to 0. set to 0.
If the 'giaddr' field in a DHCP message from a client is non-zero, If the 'giaddr' field in a DHCP message from a client is non-zero,
the server sends any return messages to the 'DHCP server' port on the the server sends any return messages to the 'DHCP server' port on the
BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr' BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
skipping to change at page 24, line 6 skipping to change at page 24, line 4
the 255 octets available to a single option (e.g., a list of routers the 255 octets available to a single option (e.g., a list of routers
in a 'router' option [21]). Options may appear only once, unless in a 'router' option [21]). Options may appear only once, unless
otherwise specified in the options document. The client concatenates otherwise specified in the options document. The client concatenates
the values of multiple instances of the same option into a single the values of multiple instances of the same option into a single
parameter list for configuration. parameter list for configuration.
DHCP clients are responsible for all message retransmission. The DHCP clients are responsible for all message retransmission. The
client MUST adopt a retransmission strategy that incorporates a client MUST adopt a retransmission strategy that incorporates a
randomized exponential backoff algorithm to determine the delay randomized exponential backoff algorithm to determine the delay
between retransmissions. The delay between retransmissions SHOULD be between retransmissions. The delay between retransmissions SHOULD be
DRAFT Dynamic Host Configuration Protocol November 1996
chosen to allow sufficient time for replies from the server to be chosen to allow sufficient time for replies from the server to be
delivered based on the characteristics of the internetwork between delivered based on the characteristics of the internetwork between
the client and the server. For example, in a 10Mb/sec Ethernet the client and the server. For example, in a 10Mb/sec Ethernet
internetwork, the delay before the first retransmission SHOULD be 4 internetwork, the delay before the first retransmission SHOULD be 4
seconds randomized by the value of a uniform random number chosen seconds randomized by the value of a uniform random number chosen
from the range -1 to +1. Clients with clocks that provide resolution from the range -1 to +1. Clients with clocks that provide resolution
granularity of less than one second may choose a non-integer granularity of less than one second may choose a non-integer
randomization value. The delay before the next retransmission SHOULD randomization value. The delay before the next retransmission SHOULD
be 8 seconds randomized by the value of a uniform number chosen from be 8 seconds randomized by the value of a uniform number chosen from
the range -1 to +1. The retransmission delay SHOULD be doubled with the range -1 to +1. The retransmission delay SHOULD be doubled with
skipping to change at page 25, line 7 skipping to change at page 25, line 4
DHCPREQUEST messages that client sends. The BROADCAST bit will DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to the DHCP server and BOOTP relay agent to broadcast provide a hint to the DHCP server and BOOTP relay agent to broadcast
any messages to the client on the client's subnet. A client that can any messages to the client on the client's subnet. A client that can
receive unicast IP datagrams before its protocol software has been receive unicast IP datagrams before its protocol software has been
configured SHOULD clear the BROADCAST bit to 0. The BOOTP configured SHOULD clear the BROADCAST bit to 0. The BOOTP
clarifications document discusses the ramifications of the use of the clarifications document discusses the ramifications of the use of the
BROADCAST bit [21]. BROADCAST bit [21].
A server or relay agent sending or relaying a DHCP message directly A server or relay agent sending or relaying a DHCP message directly
to a DHCP client (i.e., not to a relay agent specified in the to a DHCP client (i.e., not to a relay agent specified in the
DRAFT Dynamic Host Configuration Protocol November 1996
'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
field. If this bit is set to 1, the DHCP message SHOULD be sent as field. If this bit is set to 1, the DHCP message SHOULD be sent as
an IP broadcast using an IP broadcast address (preferably 0xffffffff) an IP broadcast using an IP broadcast address (preferably 0xffffffff)
as the IP destination address and the link-layer broadcast address as as the IP destination address and the link-layer broadcast address as
the link-layer destination address. If the BROADCAST bit is cleared the link-layer destination address. If the BROADCAST bit is cleared
to 0, the message SHOULD be sent as an IP unicast to the IP address to 0, the message SHOULD be sent as an IP unicast to the IP address
specified in the 'yiaddr' field and the link-layer address specified specified in the 'yiaddr' field and the link-layer address specified
in the 'chaddr' field. If unicasting is not possible, the message in the 'chaddr' field. If unicasting is not possible, the message
MAY be sent as an IP broadcast using an IP broadcast address MAY be sent as an IP broadcast using an IP broadcast address
(preferably 0xffffffff) as the IP destination address and the link- (preferably 0xffffffff) as the IP destination address and the link-
skipping to change at page 25, line 35 skipping to change at page 25, line 35
to clients that have been previously registered through some external to clients that have been previously registered through some external
mechanism. The DHCP specification describes only the interactions mechanism. The DHCP specification describes only the interactions
between clients and servers when the clients and servers choose to between clients and servers when the clients and servers choose to
interact; it is beyond the scope of the DHCP specification to interact; it is beyond the scope of the DHCP specification to
describe all of the administrative controls that system describe all of the administrative controls that system
administrators might want to use. Specific DHCP server administrators might want to use. Specific DHCP server
implementations may incorporate any controls or policies desired by a implementations may incorporate any controls or policies desired by a
network administrator. network administrator.
In some environments, a DHCP server will have to consider the values In some environments, a DHCP server will have to consider the values
of the vendor and user class options included in DHCPDISCOVER or of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
DHCPREQUEST messages when determining the correct parameters for a messages when determining the correct parameters for a particular
particular client. For example, an organization might have a client.
separate printer server for each type of end-user, requiring the DHCP
server to examine the 'user class identifier' to determine which
printer server address to return in a DHCPOFFER or DHCPACK message.
A DHCP server needs to use some unique identifier to associate a A DHCP server needs to use some unique identifier to associate a
client with its lease. The client MAY choose to explicitly provide client with its lease. The client MAY choose to explicitly provide
the identifier through the 'client identifier' option. If the client the identifier through the 'client identifier' option. If the client
supplies a 'client identifier', the client MUST use the same 'client supplies a 'client identifier', the client MUST use the same 'client
identifier' in all subsequent messages, and the server MUST use that identifier' in all subsequent messages, and the server MUST use that
identifier to identify the client. If the client does not provide a identifier to identify the client. If the client does not provide a
'client identifier' option, the server MUST use the contents of the 'client identifier' option, the server MUST use the contents of the
'chaddr' field to identify the client. It is crucial for a DHCP 'chaddr' field to identify the client. It is crucial for a DHCP
client to use an identifier unique within the subnet to which the client to use an identifier unique within the subnet to which the
client is attached in the 'client identifier' option. Use of client is attached in the 'client identifier' option. Use of
'chaddr' as the client's unique identifier may cause unexpected 'chaddr' as the client's unique identifier may cause unexpected
results, as that identifier may be associated with a hardware results, as that identifier may be associated with a hardware
interface that could be moved to a new client. Some sites may choose interface that could be moved to a new client. Some sites may choose
to use a manufacturer's serial number as the 'client identifier', to to use a manufacturer's serial number as the 'client identifier', to
avoid unexpected changes in a clients network address due to transfer avoid unexpected changes in a clients network address due to transfer
of hardware interfaces among computers. Sites may also choose to use of hardware interfaces among computers. Sites may also choose to use
DRAFT Dynamic Host Configuration Protocol November 1996
a DNS name as the 'client identifier', causing address leases to be a DNS name as the 'client identifier', causing address leases to be
associated with the DNS name rather than a specific hardware box. associated with the DNS name rather than a specific hardware box.
DHCP clients are free to use any strategy in selecting a DHCP server DHCP clients are free to use any strategy in selecting a DHCP server
among those from which the client receives a DHCPOFFER message. The among those from which the client receives a DHCPOFFER message. The
client implementation of DHCP SHOULD provide a mechanism for the user client implementation of DHCP SHOULD provide a mechanism for the user
to select directly the 'vendor class identifier' and 'user class to select directly the 'vendor class identifier' values.
identifier' values.
4.3 DHCP server behavior 4.3 DHCP server behavior
A DHCP server processes incoming DHCP messages from a client based on A DHCP server processes incoming DHCP messages from a client based on
the current state of the binding for that client. A DHCP server can the current state of the binding for that client. A DHCP server can
receive the following messages from a client: receive the following messages from a client:
o DHCPDISCOVER o DHCPDISCOVER
o DHCPREQUEST o DHCPREQUEST
skipping to change at page 27, line 10 skipping to change at page 27, line 4
o The client's previous address as recorded in the client's (now o The client's previous address as recorded in the client's (now
expired or released) binding, if that address is in the server's expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE pool of available addresses and not already allocated, ELSE
o The address requested in the 'Requested IP Address' option, if that o The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE address is valid and not already allocated, ELSE
o A new address allocated from the server's pool of available o A new address allocated from the server's pool of available
addresses; the address is selected based on the subnet from which addresses; the address is selected based on the subnet from which
DRAFT Dynamic Host Configuration Protocol November 1996
the message was received (if 'giaddr' is 0) or on the address of the message was received (if 'giaddr' is 0) or on the address of
the relay agent that forwarded the message ('giaddr' when not 0). the relay agent that forwarded the message ('giaddr' when not 0).
As described in section 4.2, a server MAY, for administrative As described in section 4.2, a server MAY, for administrative
reasons, assign an address other than the one requested, or may reasons, assign an address other than the one requested, or may
refuse to allocate an address to a particular client even though free refuse to allocate an address to a particular client even though free
addresses are available. addresses are available.
Note that, in some network architectures (e.g., internets with more Note that, in some network architectures (e.g., internets with more
than one IP subnet assigned to a physical network segment), it may be than one IP subnet assigned to a physical network segment), it may be
skipping to change at page 28, line 5 skipping to change at page 28, line 5
DHCPDISCOVER message and the client does not have an assigned DHCPDISCOVER message and the client does not have an assigned
network address, the server assigns a locally configured default network address, the server assigns a locally configured default
lease time, ELSE lease time, ELSE
o IF the client has requested a specific lease in the DHCPDISCOVER o IF the client has requested a specific lease in the DHCPDISCOVER
message (regardless of whether the client has an assigned network message (regardless of whether the client has an assigned network
address), the server may choose either to return the requested address), the server may choose either to return the requested
lease (if the lease is acceptable to local policy) or select lease (if the lease is acceptable to local policy) or select
another lease. another lease.
DRAFT Dynamic Host Configuration Protocol November 1996
Field DHCPOFFER DHCPACK DHCPNAK Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- ------- ----- --------- ------- -------
'op' BOOTREPLY BOOTREPLY BOOTREPLY 'op' BOOTREPLY BOOTREPLY BOOTREPLY
'htype' (From "Assigned Numbers" RFC) 'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets) 'hlen' (Hardware address length in octets)
'hops' 0 0 0 'hops' 0 0 0
'xid' 'xid' from client 'xid' from client 'xid' from client 'xid' 'xid' from client 'xid' from client 'xid' from client
DHCPDISCOVER DHCPREQUEST DHCPREQUEST DHCPDISCOVER DHCPREQUEST DHCPREQUEST
message message message message message message
'secs' 0 0 0 'secs' 0 0 0
skipping to change at page 28, line 47 skipping to change at page 28, line 49
------ --------- ------- ------- ------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST NOT Requested IP address MUST NOT MUST NOT MUST NOT
IP address lease time MUST MUST (DHCPREQUEST) MUST NOT IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
MUST NOT (DHCPINFORM) MUST NOT (DHCPINFORM)
Use 'file'/'sname' fields MAY MAY MUST NOT Use 'file'/'sname' fields MAY MAY MUST NOT
DHCP message type DHCPOFFER DHCPACK DHCPNAK DHCP message type DHCPOFFER DHCPACK DHCPNAK
Parameter request list MUST NOT MUST NOT MUST NOT Parameter request list MUST NOT MUST NOT MUST NOT
Message SHOULD SHOULD SHOULD Message SHOULD SHOULD SHOULD
Client identifier MUST NOT MUST NOT MAY Client identifier MUST NOT MUST NOT MAY
Vendor class identifier MAY MAY MAY Vendor class identifier MAY MAY MAY
User class identifier MUST MUST MAY
Server identifier MUST MUST MUST Server identifier MUST MUST MUST
Maximum message size MUST NOT MUST NOT MUST NOT Maximum message size MUST NOT MUST NOT MUST NOT
All others MAY MAY MUST NOT All others MAY MAY MUST NOT
Table 3: Fields and options used by DHCP servers Table 3: Fields and options used by DHCP servers
DRAFT Dynamic Host Configuration Protocol November 1996
Once the network address and lease have been determined, the server Once the network address and lease have been determined, the server
constructs a DHCPOFFER message with the offered configuration constructs a DHCPOFFER message with the offered configuration
parameters. It is important for all DHCP servers to return the same parameters. It is important for all DHCP servers to return the same
parameters (with the possible exception of a newly allocated network parameters (with the possible exception of a newly allocated network
address) to ensure predictable client behavior regardless of which address) to ensure predictable client behavior regardless of which
server the client selects. The configuration parameters MUST be server the client selects. The configuration parameters MUST be
selected by applying the following rules in the order given below. selected by applying the following rules in the order given below.
The network administrator is responsible for configuring multiple The network administrator is responsible for configuring multiple
DHCP servers to ensure uniform responses from those servers. The DHCP servers to ensure uniform responses from those servers. The
server MUST return to the client: server MUST return to the client:
skipping to change at page 30, line 5 skipping to change at page 30, line 5
Extensions document. Extensions document.
o Any parameters from the existing binding that differ from the Host o Any parameters from the existing binding that differ from the Host
Requirements Document defaults, Requirements Document defaults,
o Any parameters specific to this client (as identified by o Any parameters specific to this client (as identified by
the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
or DHCPREQUEST message), e.g., as configured by the network or DHCPREQUEST message), e.g., as configured by the network
administrator, administrator,
DRAFT Dynamic Host Configuration Protocol November 1996
o Any parameters specific to this client's class (as identified o Any parameters specific to this client's class (as identified
by the contents of the 'vendor class identifier' or 'user class by the contents of the 'vendor class identifier'
identifier' options in the DHCPDISCOVER or DHCPREQUEST message), option in the DHCPDISCOVER or DHCPREQUEST message),
e.g., as configured by the network administrator; the parameters e.g., as configured by the network administrator; the parameters
MUST be identified by an exact match between the client's vendor and MUST be identified by an exact match between the client's vendor
user class identifiers and the client's classes identified in the class identifiers and the client's classes identified in the
server, server,
o Parameters with non-default values on the client's subnet. o Parameters with non-default values on the client's subnet.
The server MAY choose to return the 'vendor class identifier' and The server MAY choose to return the 'vendor class identifier' used to
MUST return the 'user class identifier' used to determine the determine the parameters in the DHCPOFFER message to assist the
parameters in the DHCPOFFER message to assist the client in selecting client in selecting which DHCPOFFER to accept. The server inserts
which DHCPOFFER to accept. The server inserts the 'xid' field from the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
the DHCPDISCOVER message into the 'xid' field of the DHCPOFFER the DHCPOFFER message and sends the DHCPOFFER message to the
message and sends the DHCPOFFER message to the requesting client. requesting client.
4.3.2 DHCPREQUEST message 4.3.2 DHCPREQUEST message
A DHCPREQUEST message may come from a client responding to a A DHCPREQUEST message may come from a client responding to a
DHCPOFFER message from a server, from a client verifying a previously DHCPOFFER message from a server, from a client verifying a previously
allocated IP address or from a client extending the lease on a allocated IP address or from a client extending the lease on a
network address. If the DHCPREQUEST message contains a 'server network address. If the DHCPREQUEST message contains a 'server
identifier' option, the message is in response to a DHCPOFFER identifier' option, the message is in response to a DHCPOFFER
message. Otherwise, the message is a request to verify or extend an message. Otherwise, the message is a request to verify or extend an
existing lease. If the client uses a 'client identifier' in a existing lease. If the client uses a 'client identifier' in a
skipping to change at page 31, line 4 skipping to change at page 31, line 4
o DHCPREQUEST generated during SELECTING state: o DHCPREQUEST generated during SELECTING state:
Client inserts the address of the selected server in 'server Client inserts the address of the selected server in 'server
identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
filled in with the yiaddr value from the chosen DHCPOFFER. filled in with the yiaddr value from the chosen DHCPOFFER.
Note that the client may choose to collect several DHCPOFFER Note that the client may choose to collect several DHCPOFFER
messages and select the "best" offer. The client indicates its messages and select the "best" offer. The client indicates its
selection by identifying the offering server in the DHCPREQUEST selection by identifying the offering server in the DHCPREQUEST
message. If the client receives no acceptable offers, the client message. If the client receives no acceptable offers, the client
DRAFT Dynamic Host Configuration Protocol November 1996
may choose to try another DHCPDISCOVER message. Therefore, the may choose to try another DHCPDISCOVER message. Therefore, the
servers may not receive a specific DHCPREQUEST from which they can servers may not receive a specific DHCPREQUEST from which they can
decide whether or not the client has accepted the offer. Because decide whether or not the client has accepted the offer. Because
the servers have not committed any network address assignments on the servers have not committed any network address assignments on
the basis of a DHCPOFFER, servers are free to reuse offered network the basis of a DHCPOFFER, servers are free to reuse offered network
addresses in response to subsequent requests. As an implementation addresses in response to subsequent requests. As an implementation
detail, servers SHOULD NOT reuse offered addresses and may use an detail, servers SHOULD NOT reuse offered addresses and may use an
implementation-specific timeout mechanism to decide when to reuse implementation-specific timeout mechanism to decide when to reuse
an offered address. an offered address.
skipping to change at page 32, line 5 skipping to change at page 32, line 5
message to the 0xffffffff broadcast address because the client may message to the 0xffffffff broadcast address because the client may
not have a correct network address or subnet mask, and the client not have a correct network address or subnet mask, and the client
may not be answering ARP requests. may not be answering ARP requests.
If 'giaddr' is set in the DHCPREQUEST message, the client is on a If 'giaddr' is set in the DHCPREQUEST message, the client is on a
different subnet. The server MUST set the broadcast bit in the different subnet. The server MUST set the broadcast bit in the
DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
client, because the client may not have a correct network address client, because the client may not have a correct network address
or subnet mask, and the client may not be answering ARP requests. or subnet mask, and the client may not be answering ARP requests.
DRAFT Dynamic Host Configuration Protocol November 1996
o DHCPREQUEST generated during RENEWING state: o DHCPREQUEST generated during RENEWING state:
'server identifier' MUST NOT be filled in, 'requested IP address' 'server identifier' MUST NOT be filled in, 'requested IP address'
option MUST NOT be filled in, 'ciaddr' MUST be filled in with option MUST NOT be filled in, 'ciaddr' MUST be filled in with
client's IP address. In this situation, the client is completely client's IP address. In this situation, the client is completely
configured, and is trying to extend its lease. This message will be configured, and is trying to extend its lease. This message will be
unicast, so no relay agents will be involved in its transmission. unicast, so no relay agents will be involved in its transmission.
Because 'giaddr' is therefore not filled in, the DHCP server will Because 'giaddr' is therefore not filled in, the DHCP server will
trust the value in 'ciaddr', and use it when replying to the trust the value in 'ciaddr', and use it when replying to the
client. client.
skipping to change at page 33, line 4 skipping to change at page 33, line 4
a possible configuration problem. a possible configuration problem.
4.3.4 DHCPRELEASE message 4.3.4 DHCPRELEASE message
Upon receipt of a DHCPRELEASE message, the server marks the network Upon receipt of a DHCPRELEASE message, the server marks the network
address as not allocated. The server SHOULD retain a record of the address as not allocated. The server SHOULD retain a record of the
client's initialization parameters for possible reuse in response to client's initialization parameters for possible reuse in response to
subsequent requests from the client. subsequent requests from the client.
4.3.5 DHCPINFORM message 4.3.5 DHCPINFORM message
DRAFT Dynamic Host Configuration Protocol November 1996
The server responds to a DHCPINFORM message by sending a DHCPACK The server responds to a DHCPINFORM message by sending a DHCPACK
message directly to the address given in the 'ciaddr' field of the message directly to the address given in the 'ciaddr' field of the
DHCPINFORM message. The server SHOULD NOT send a lease expiration DHCPINFORM message. The server MUST NOT send a lease expiration time
time to the client and SHOULD NOT fill in 'yiaddr'. The server to the client and SHOULD NOT fill in 'yiaddr'. The server includes
includes other parameters in the DHCPACK message as defined in other parameters in the DHCPACK message as defined in section 4.3.1.
section 4.3.1.
4.3.6 Client messages 4.3.6 Client messages
Table 4 details the differences between messages from clients in Table 4 details the differences between messages from clients in
various states. various states.
--------------------------------------------------------------------- ---------------------------------------------------------------------
| |INIT-REBOOT |SELECTING |RENEWING |REBINDING | | |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
--------------------------------------------------------------------- ---------------------------------------------------------------------
|broad/unicast |broadcast |broadcast |unicast |broadcast | |broad/unicast |broadcast |broadcast |unicast |broadcast |
skipping to change at page 34, line 5 skipping to change at page 34, line 5
process. process.
Table 5 gives the use of the fields and options in a DHCP message by Table 5 gives the use of the fields and options in a DHCP message by
a client. The remainder of this section describes the action of the a client. The remainder of this section describes the action of the
DHCP client for each possible incoming message. The description in DHCP client for each possible incoming message. The description in
the following section corresponds to the full configuration procedure the following section corresponds to the full configuration procedure
previously described in section 3.1, and the text in the subsequent previously described in section 3.1, and the text in the subsequent
section corresponds to the abbreviated configuration procedure section corresponds to the abbreviated configuration procedure
described in section 3.2. described in section 3.2.
DRAFT Dynamic Host Configuration Protocol November 1996
-------- ------- -------- -------
| | +-------------------------->| |<-------------------+ | | +-------------------------->| |<-------------------+
| INIT- | | +-------------------->| INIT | | | INIT- | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ | | REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Restart| | ------- | | | |Restart| | ------- | |
-------- | DHCPNAK/ | | | -------- | DHCPNAK/ | | |
| Discard offer | -/Send DHCPDISCOVER | | Discard offer | -/Send DHCPDISCOVER |
-/Send DHCPREQUEST | | | -/Send DHCPREQUEST | | |
| | | DHCPACK v | | | | | DHCPACK v | |
----------- | (not accept.)/ ----------- | | ----------- | (not accept.)/ ----------- | |
skipping to change at page 35, line 5 skipping to change at page 35, line 5
T1 expires/ Record lease, set | | T1 expires/ Record lease, set | |
Send DHCPREQUEST timers T1, T2 | | Send DHCPREQUEST timers T1, T2 | |
to leasing server | | | to leasing server | | |
| ---------- | | | ---------- | |
| | |------------+ | | | |------------+ |
+->| RENEWING | | +->| RENEWING | |
| |----------------------------+ | |----------------------------+
---------- ----------
Figure 5: State-transition diagram for DHCP clients Figure 5: State-transition diagram for DHCP clients
DRAFT Dynamic Host Configuration Protocol November 1996
4.4.1 Initialization and allocation of network address 4.4.1 Initialization and allocation of network address
The client begins in INIT state and forms a DHCPDISCOVER message. The client begins in INIT state and forms a DHCPDISCOVER message.
The client SHOULD wait a random time between one and ten seconds to The client SHOULD wait a random time between one and ten seconds to
desynchronize the use of DHCP at startup. The client sets 'ciaddr' desynchronize the use of DHCP at startup. The client sets 'ciaddr'
to 0x00000000. The client MAY request specific parameters by to 0x00000000. The client MAY request specific parameters by
including the 'parameter request list' option. The client MAY including the 'parameter request list' option. The client MAY
suggest a network address and/or lease time by including the suggest a network address and/or lease time by including the
'requested IP address' and 'IP address lease time' options. The 'requested IP address' and 'IP address lease time' options. The
client MUST include its hardware address in the 'chaddr' field, if client MUST include its hardware address in the 'chaddr' field, if
skipping to change at page 36, line 5 skipping to change at page 36, line 5
silently discarded. silently discarded.
The client collects DHCPOFFER messages over a period of time, selects The client collects DHCPOFFER messages over a period of time, selects
one DHCPOFFER message from the (possibly many) incoming DHCPOFFER one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
messages (e.g., the first DHCPOFFER message or the DHCPOFFER message messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
from the previously used server) and extracts the server address from from the previously used server) and extracts the server address from
the 'server identifier' option in the DHCPOFFER message. The time the 'server identifier' option in the DHCPOFFER message. The time
over which the client collects messages and the mechanism used to over which the client collects messages and the mechanism used to
select one DHCPOFFER are implementation dependent. select one DHCPOFFER are implementation dependent.
DRAFT Dynamic Host Configuration Protocol November 1996
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE, Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE DHCPINFORM DHCPRELEASE
----- ------------ ----------- ----------- ----- ------------ ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST 'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (From "Assigned Numbers" RFC) 'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets) 'hlen' (Hardware address length in octets)
'hops' 0 0 0 'hops' 0 0 0
'xid' selected by client 'xid' from server selected by 'xid' selected by client 'xid' from server selected by
DHCPOFFER message client DHCPOFFER message client
'secs' 0 or seconds since 0 or seconds since 0 'secs' 0 or seconds since 0 or seconds since 0
skipping to change at page 37, line 4 skipping to change at page 37, line 4
------ ------------ ----------- ----------- ------ ------------ ----------- -----------
Requested IP address MAY MUST (in MUST Requested IP address MAY MUST (in MUST
(DISCOVER) SELECTING or (DHCPDECLINE), (DISCOVER) SELECTING or (DHCPDECLINE),
MUST NOT INIT-REBOOT) MUST NOT MUST NOT INIT-REBOOT) MUST NOT
(INFORM) MUST NOT (in (DHCPRELEASE) (INFORM) MUST NOT (in (DHCPRELEASE)
BOUND or BOUND or
RENEWING) RENEWING)
IP address lease time MAY MAY MUST NOT IP address lease time MAY MAY MUST NOT
(DISCOVER) (DISCOVER)
MUST NOT MUST NOT
DRAFT Dynamic Host Configuration Protocol November 1996
(INFORM) (INFORM)
Use 'file'/'sname' fields MAY MAY MAY Use 'file'/'sname' fields MAY MAY MAY
DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/ DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
DHCPINFORM DHCPRELEASE DHCPINFORM DHCPRELEASE
Client identifier MAY MAY MAY Client identifier MAY MAY MAY
Vendor class identifier MAY MAY MUST NOT Vendor class identifier MAY MAY MUST NOT
User class identifier MAY MAY MUST NOT
Server identifier MUST NOT MUST (after MUST Server identifier MUST NOT MUST (after MUST
SELECTING) SELECTING)
MUST NOT (after MUST NOT (after
INIT-REBOOT, INIT-REBOOT,
BOUND, RENEWING BOUND, RENEWING
or REBINDING) or REBINDING)
Parameter request list MAY MAY MUST NOT Parameter request list MAY MAY MUST NOT
Maximum message size MAY MAY MUST NOT Maximum message size MAY MAY MUST NOT
Message SHOULD NOT SHOULD NOT SHOULD Message SHOULD NOT SHOULD NOT SHOULD
Site-specific MAY MAY MUST NOT Site-specific MAY MAY MUST NOT
skipping to change at page 37, line 49 skipping to change at page 37, line 51
hardware address, and 0 as the sender's IP address, to avoid hardware address, and 0 as the sender's IP address, to avoid
confusing ARP caches in other hosts on the same subnet. If the confusing ARP caches in other hosts on the same subnet. If the
network address appears to be in use, the client MUST send a network address appears to be in use, the client MUST send a
DHCPDECLINE message to the server. The client SHOULD broadcast an ARP DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
reply to announce the client's new IP address and clear any outdated reply to announce the client's new IP address and clear any outdated
ARP cache entries in hosts on the client's subnet. ARP cache entries in hosts on the client's subnet.
4.4.2 Initialization with known network address 4.4.2 Initialization with known network address
The client begins in INIT-REBOOT state and sends a DHCPREQUEST The client begins in INIT-REBOOT state and sends a DHCPREQUEST
message. The client may request specific configuration parameters by message. The client MUST insert its known network address as a
including the 'parameter request list' option. The client generates 'requested IP address' option in the DHCPREQUEST message. The client
and records a random transaction identifier and inserts that may request specific configuration parameters by including the
identifier into the 'xid' field. The client records its own local 'parameter request list' option. The client generates and records a
time for later use in computing the lease expiration. The client
MUST NOT include a 'server identifier' in the DHCPREQUEST message. DRAFT Dynamic Host Configuration Protocol November 1996
The client then broadcasts the DHCPREQUEST on the local hardware
broadcast address to the 'DHCP server' UDP port. random transaction identifier and inserts that identifier into the
'xid' field. The client records its own local time for later use in
computing the lease expiration. The client MUST NOT include a
'server identifier' in the DHCPREQUEST message. The client then
broadcasts the DHCPREQUEST on the local hardware broadcast address to
the 'DHCP server' UDP port.
Once a DHCPACK message with an 'xid' field matching that in the Once a DHCPACK message with an 'xid' field matching that in the
client's DHCPREQUEST message arrives from any server, the client is client's DHCPREQUEST message arrives from any server, the client is
initialized and moves to BOUND state. The client records the lease initialized and moves to BOUND state. The client records the lease
expiration time as the sum of the time at which the DHCPREQUEST expiration time as the sum of the time at which the DHCPREQUEST
message was sent and the duration of the lease from the DHCPACK message was sent and the duration of the lease from the DHCPACK
message. message.
4.4.3 Initialization with an externally assigned network address 4.4.3 Initialization with an externally assigned network address
skipping to change at page 38, line 47 skipping to change at page 38, line 51
4.1), then it SHOULD display a message informing the user of the 4.1), then it SHOULD display a message informing the user of the
problem, and then SHOULD begin network processing using suitable problem, and then SHOULD begin network processing using suitable
defaults as per Appendix A. defaults as per Appendix A.
4.4.4 Use of broadcast and unicast 4.4.4 Use of broadcast and unicast
The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
messages, unless the client knows the address of a DHCP server. The messages, unless the client knows the address of a DHCP server. The
client unicasts DHCPRELEASE messages to the server. Because the client unicasts DHCPRELEASE messages to the server. Because the
client is declining the use of the IP address supplied by the server, client is declining the use of the IP address supplied by the server,
the client broadcsts DHCPDECLINE messages. the client broadcasts DHCPDECLINE messages.
When the DHCP client knows the address of a DHCP server, in either When the DHCP client knows the address of a DHCP server, in either
INIT or REBOOTING state, the client may use that address in the INIT or REBOOTING state, the client may use that address in the
DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
DRAFT Dynamic Host Configuration Protocol November 1996
DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
The client may also use unicast to send DHCPINFORM messages to a The client may also use unicast to send DHCPINFORM messages to a
known DHCP server. If the client receives no response to DHCP known DHCP server. If the client receives no response to DHCP
messages sent to the IP address of a known DHCP server, the DHCP messages sent to the IP address of a known DHCP server, the DHCP
client reverts to using the IP broadcast address. client reverts to using the IP broadcast address.
4.4.5 Reacquisition and expiration 4.4.5 Reacquisition and expiration
The client maintains two times, T1 and T2, that specify the times at The client maintains two times, T1 and T2, that specify the times at
which the client tries to extend its lease on its network address. which the client tries to extend its lease on its network address.
T1 is the time at which the client enters the RENEWING state and T1 is the time at which the client enters the RENEWING state and
skipping to change at page 40, line 5 skipping to change at page 40, line 5
lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its
current network address. The client MUST NOT include a 'server current network address. The client MUST NOT include a 'server
identifier' in the DHCPREQUEST message. identifier' in the DHCPREQUEST message.
Times T1 and T2 are configurable by the server through options. T1 Times T1 and T2 are configurable by the server through options. T1
defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
duration_of_lease). Times T1 and T2 SHOULD be chosen with some duration_of_lease). Times T1 and T2 SHOULD be chosen with some
random "fuzz" around a fixed value, to avoid synchronization of random "fuzz" around a fixed value, to avoid synchronization of
client reacquisition. client reacquisition.
DRAFT Dynamic Host Configuration Protocol November 1996
A client MAY choose to renew or extend its lease prior to T1. The A client MAY choose to renew or extend its lease prior to T1. The
server MAY choose to extend the client's lease according to policy server MAY choose to extend the client's lease according to policy
set by the network administrator. The server SHOULD return T1 and set by the network administrator. The server SHOULD return T1 and
T2, and their values SHOULD be adjusted from their original values to T2, and their values SHOULD be adjusted from their original values to
take account of the time remaining on the lease. take account of the time remaining on the lease.
In both RENEWING and REBINDING states, if the client receives no In both RENEWING and REBINDING states, if the client receives no
response to its DHCPREQUEST message, the client SHOULD wait one-half response to its DHCPREQUEST message, the client SHOULD wait one-half
of the remaining time until T2 (in RENEWING state) and one-half of of the remaining time until T2 (in RENEWING state) and one-half of
the remaining lease time (in REBINDING state), down to a minimum of the remaining lease time (in REBINDING state), down to a minimum of
skipping to change at page 40, line 33 skipping to change at page 40, line 35
network address, it MUST NOT continue using the previous network network address, it MUST NOT continue using the previous network
address and SHOULD notify the local users of the problem. address and SHOULD notify the local users of the problem.
4.4.6 DHCPRELEASE 4.4.6 DHCPRELEASE
If the client no longer requires use of its assigned network address If the client no longer requires use of its assigned network address
(e.g., the client is gracefully shut down), the client sends a (e.g., the client is gracefully shut down), the client sends a
DHCPRELEASE message to the server. Note that the correct operation DHCPRELEASE message to the server. Note that the correct operation
of DHCP does not depend on the transmission of DHCPRELEASE messages. of DHCP does not depend on the transmission of DHCPRELEASE messages.
5. References 5. Acknowledgments
The author thanks the many (and too numerous to mention!) members of
the DHC WG for their tireless and ongoing efforts in the development
of DHCP and this document.
The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
Mendonca in organizing DHCP interoperability testing sessions are
gratefully acknowledged.
The development of this document was supported in part by grants from
the Corporation for National Research Initiatives (CNRI), Bucknell
University and Sun Microsystems.
DRAFT Dynamic Host Configuration Protocol November 1996
6. References
[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
1983. 1983.
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, Lachman Technology, Inc., Bucknell Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
University, October 1993. University, October 1993.
[3] Braden, R., Editor, "Requirements for Internet Hosts -- [3] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, USC/Information Sciences Communication Layers", STD 3, RFC 1122, USC/Information Sciences
skipping to change at page 41, line 32 skipping to change at page 42, line 5
Mechanism for Distributed File Cache Consistency", In Proc. of Mechanism for Distributed File Cache Consistency", In Proc. of
the Twelfth ACM Symposium on Operating Systems Design, 1989. the Twelfth ACM Symposium on Operating Systems Design, 1989.
[12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987. 13, RFC 1034, USC/Information Sciences Institute, November 1987.
[13] Mockapetris, P., "Domain Names -- Implementation and [13] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987. Institute, November 1987.
DRAFT Dynamic Host Configuration Protocol November 1996
[14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990. November 1990.
[15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
Hosts", Work in Progress. Hosts", Work in Progress.
[16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
USC/Information Sciences Institute, September 1981. USC/Information Sciences Institute, September 1981.
[17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
skipping to change at page 42, line 8 skipping to change at page 42, line 32
[19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
Assignment of IP Addresses for use on an Ethernet. (Available Assignment of IP Addresses for use on an Ethernet. (Available
from the Athena Project, MIT), 1989. from the Athena Project, MIT), 1989.
[20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
June 1981. June 1981.
[21] Wimer, W., "Clarifications and Extensions for the Bootstrap [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, Carnegie Mellon University, October 1993. Protocol", RFC 1542, Carnegie Mellon University, October 1993.
6. Security Considerations 7. Security Considerations
DHCP is built directly on UDP and IP which are as yet inherently DHCP is built directly on UDP and IP which are as yet inherently
insecure. Furthermore, DHCP is generally intended to make insecure. Furthermore, DHCP is generally intended to make
maintenance of remote and/or diskless hosts easier. While perhaps maintenance of remote and/or diskless hosts easier. While perhaps
not impossible, configuring such hosts with passwords or keys may be not impossible, configuring such hosts with passwords or keys may be
difficult and inconvenient. Therefore, DHCP in its current form is difficult and inconvenient. Therefore, DHCP in its current form is
quite insecure. quite insecure.
Unauthorized DHCP servers may be easily set up. Such servers can Unauthorized DHCP servers may be easily set up. Such servers can
then send false and potentially disruptive information to clients then send false and potentially disruptive information to clients
skipping to change at page 42, line 31 skipping to change at page 43, line 5
nameserver addresses (such as spoof nameservers), and so on. nameserver addresses (such as spoof nameservers), and so on.
Clearly, once this seed information is in place, an attacker can Clearly, once this seed information is in place, an attacker can
further compromise affected systems. further compromise affected systems.
Malicious DHCP clients could masquerade as legitimate clients and Malicious DHCP clients could masquerade as legitimate clients and
retrieve information intended for those legitimate clients. Where retrieve information intended for those legitimate clients. Where
dynamic allocation of resources is used, a malicious client could dynamic allocation of resources is used, a malicious client could
claim all resources for itself, thereby denying resources to claim all resources for itself, thereby denying resources to
legitimate clients. legitimate clients.
7. Author's Address DRAFT Dynamic Host Configuration Protocol November 1996
8. Author's Address
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
EMail: droms@bucknell.edu EMail: droms@bucknell.edu
This document will expire on May 30, 1996. This document will expire on May 30, 1996.
DRAFT Dynamic Host Configuration Protocol November 1996
A. Host Configuration Parameters A. Host Configuration Parameters
IP-layer_parameters,_per_host:_ IP-layer_parameters,_per_host:_
Be a router on/off HRC 3.1 Be a router on/off HRC 3.1
Non-local source routing on/off HRC 3.3.5 Non-local source routing on/off HRC 3.3.5
Policy filters for Policy filters for
non-local source routing (list) HRC 3.3.5 non-local source routing (list) HRC 3.3.5
Maximum reassembly size integer HRC 3.3.2 Maximum reassembly size integer HRC 3.3.2
Default TTL integer HRC 3.2.1.7 Default TTL integer HRC 3.2.1.7
 End of changes. 60 change blocks. 
57 lines changed or deleted 172 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/