Network Working Group R. Droms
INTERNET DRAFT Bucknell University
-Obsoletes: draft-ietf-dhc-dhcp-02.txt September 1995
- Expires March 1996
+Obsoletes: draft-ietf-dhc-dhcp-05.txt November 1995
+ Expires May 1996
Dynamic Host Configuration Protocol
- <draft-ietf-dhc-dhcp-03.txt>
+ <draft-ietf-dhc-dhcp-06.txt>
Status of this memo
1.5 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Configuration parameters repository . . . . . . . . . . . . . 10
+
+
+
+Droms [Page 1]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
2.2 Dynamic allocation of network addresses . . . . . . . . . . . 11
3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 12
3.1 Client-server interaction - allocating a network address. . . 13
3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
4. Specification of the DHCP client-server protocol. . . . . . . 22
4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
- 4.2 DHCP server administrative controls . . . . . . . . . . . . . 24
- 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 25
+ 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
+ 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 33
5. References . . . . . . . . . . . . . . . . . . . . . . . . . .40
6. Security Considerations. . . . . . . . . . . . . . . . . . . .42
DHCP server to a host and a mechanism for allocation of network
addresses to hosts.
+
+
+
+Droms [Page 2]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
DHCP is built on a client-server model, where designated DHCP server
hosts allocate network addresses and deliver configuration parameters
to dynamically configured hosts. Throughout the remainder of this
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
+
+
+
+Droms [Page 3]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
BOOTP specification [7, 21] and to allow interoperability of existing
BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
the necessity of having a DHCP server on each physical network
There are several Internet protocols and related mechanisms that
address some parts of the dynamic host configuration problem. The
-
Reverse Address Resolution Protocol (RARP) [10] (through the
extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
addresses the problem of network address discovery, and includes an
DHCP is designed to supply DHCP clients with the configuration
parameters defined in the Host Requirements RFCs. After obtaining
+
+
+
+Droms [Page 4]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
parameters via DHCP, a DHCP client should be able to exchange packets
with any other host in the Internet. The TCP/IP stack parameters
supplied by DHCP are listed in Appendix A.
and the case carefully weighed before implementing any behavior
described with this label.
+
+
+
+
+Droms [Page 5]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
o "MAY"
This word or the adjective "OPTIONAL" means that this item is
should be able to enforce local policies concerning allocation
and access to local resources where desired.
+
+
+
+
+
+
+Droms [Page 6]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
o Clients should require no manual configuration. Each client should
be able to discover appropriate local configuration parameters
without user intervention and incorporate those parameters into
possible, a DHCP client should be assigned the same configuration
parameters despite restarts of the DHCP mechanism,
- o Allow automatic assignment of configuration parameters to new
+ o Allow automated assignment of configuration parameters to new
clients to avoid hand configuration for new clients,
o Support fixed or permanent allocation of configuration
parameters to specific clients.
+
+
+
+
+
+Droms [Page 7]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
2. Protocol Summary
From the client's point of view, DHCP is an extension of the BOOTP
mechanism. This behavior allows existing BOOTP clients to
interoperate with DHCP servers without requiring any change to the
- clients' initialization software. RFC 1533 [2] details the
+ clients' initialization software. RFC 1542 [2] details the
interactions between BOOTP and DHCP clients and servers [9]. There
are some new, optional transactions that optimize the interaction
between DHCP clients and servers that are described in sections 3 and
is an opaque key, not to be interpreted by the server; for example,
the 'client identifier' may contain a hardware address, identical to
the contents of the 'chaddr' field, or it may contain another type of
- identifier, such as a DNS name. If the client uses a 'client
- identifier' in one message, it MUST use that same identifier in all
- subsequent messages, to ensure that all servers correctly identify
- the client.
+ 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
+ the client is attached. If the client uses a 'client identifier' in
+ one message, it MUST use that same identifier in all subsequent
+ messages, to ensure that all servers correctly identify the client.
+
+
+
+
+
+
+
+Droms [Page 8]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
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
datagram size an IP host must be prepared to accept [3]. DHCP
clients may negotiate the use of larger DHCP messages through the
+
+
+Droms [Page 9]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
'maximum DHCP message size' option. The options field may be further
extended into the 'file' and 'sname' fields.
For example, the key might be the pair (IP-subnet-number, hardware-
address) (note that the "hardware-address" should be typed by the
type of hardware to accommodate possible duplication of hardware
+
+
+
+Droms [Page 10]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
addresses resulting from bit-ordering problems in a mixed-media,
bridged network) allowing for serial or concurrent reuse of a
hardware address on different subnets, and for hardware addresses
different subnet or has changed hardware addresses (perhaps because
the network interface failed and was replaced). The protocol defines
that the key will be (IP-subnet-number, hardware-address) unless the
- client explicitly supplies an identifier.
+ client explicitly supplies an identifier using the 'client
+ identifier' option.
A client can query the DHCP service to retrieve its configuration
parameters. The client interface to the configuration parameters
e.g., with an ICMP echo request, and the client SHOULD probe the
newly received address, e.g., with ARP.
+
+
+
+Droms [Page 11]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
FIELD OCTETS DESCRIPTION
----- ------ -----------
The first four octets of the 'options' field of the DHCP message
contain the (decimal) values 99, 130, 83 and 99, respectively (this
is the same magic cookie as is defined in RFC 1497 [17]). The
- remainder of the 'options' field consists a list of tagged parameters
- that are called "options". All of the "vendor extensions" listed in
- RFC 1497 are also DHCP options. RFC 1533 gives the complete set of
- options defined for use with DHCP.
+ remainder of the 'options' field consists of a list of tagged
+ parameters that are called "options". All of the "vendor extensions"
+
+
+
+Droms [Page 12]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
+ listed in RFC 1497 are also DHCP options. RFC 1533 gives the
+ complete set of options defined for use with DHCP.
Several options have been defined so far. One particular option -
the "DHCP message type" option - must be included in every DHCP
configuration parameters in DHCP options). Servers need not
reserve the offered network address, although the protocol will
work more efficiently if the server avoids allocating the offered
- network address to another client. When allocating a new address
- (i.e., 'ciaddr' == 0), servers SHOULD check that the offered
- network address is not already in use; e.g., the server may probe
- the offered address with an ICMP Echo Request. Servers SHOULD be
- implemented so that network administrators MAY choose to disable
- probes of newly allocated addresses. The server transmits the
- DHCPOFFER message to the client, using the BOOTP relay agent if
- necessary.
+ network address to another client. When allocating a new address,
+ servers SHOULD check that the offered network address is not
+ already in use; e.g., the server may probe the offered address
+ with an ICMP Echo Request. Servers SHOULD be implemented so that
+ network administrators MAY choose to disable probes of newly
+ allocated addresses. The server transmits the DHCPOFFER message
+ to the client, using the BOOTP relay agent if necessary.
3. The client receives one or more DHCPOFFER messages from one or
more servers. The client may choose to wait for multiple
configuration parameters, based on the configuration parameters
offered in the DHCPOFFER messages. The client broadcasts a
DHCPREQUEST message that MUST include the 'server identifier'
+
+
+
+Droms [Page 13]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
option to indicate which server it has selected, and that MAY
include other options specifying desired configuration values.
The 'requested IP address' option MUST be set to the value of
network address.
Table 2: DHCP messages
+
+
+
+
+Droms [Page 14]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
Server Client Server
(not selected) (selected)
Figure 3: Timeline diagram of messages exchanged between DHCP
client and servers when allocating a new network address
+
+
+
+
+
+
+Droms [Page 15]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
4. The servers receive the DHCPREQUEST broadcast from the client.
Those servers not selected by the DHCPREQUEST message use the
message as notification that the client has declined that server's
that client) to wait overly long before giving up; e.g., a client
retransmitting as described in section 4.1 might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds,
+
+
+
+Droms [Page 16]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
before restarting the initialization procedure. If the client
receives neither a DHCPACK or a DHCPNAK message after employing the
retransmission algorithm, the client reverts to INIT state and
SHOULD NOT respond with a DHCPNAK unless the servers are using an
explicit mechanism to maintain coherency among the servers.
+
+
+
+
+
+
+
+Droms [Page 17]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
Server Client Server
v v v
network address
- If 'giaddr' in the DHCPREQUEST message contains 0x0, the server sends
- the DHCPNAK message directly to the client, as the client is on the
- same subnet. Otherwise, the server send the DHCPNAK message to the IP
+ If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
+ the same subnet as the server. The server MUST
+ broadcast the DHCPNAK message to the 0xffffffff broadcast address
+ because the client may not have a correct network address or subnet
+ mask, and the client may not be answering ARP requests.
+ Otherwise, the server send the DHCPNAK message to the IP
address of the BOOTP relay agent, as recorded in 'giaddr'. The
relay agent will, in turn, forward the message directly to the
client's hardware address, so that the DHCPNAK can be delivered even
if the client has moved to a new network.
+
+
+
+
+Droms [Page 18]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
3. The client receives the DHCPACK message with configuration
parameters. The client performs a final check on the parameters
(as in section 3.1), and notes the duration of the lease specified
address locally, the client will not normally relinquish its
lease during a graceful shutdown. Only in the case where the
client explicitly needs to relinquish its lease, e.g., the client
+
+
+
+Droms [Page 19]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
is about to be moved to a different subnet, will the client send
a DHCPRELEASE message.
Not all clients require initialization of all parameters listed in
Appendix A. Two techniques are used to reduce the number of
parameters transmitted from the server to the client. First, most of
+
+
+
+Droms [Page 20]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
the parameters have defaults defined in the Host Requirements RFCs;
if the client receives no parameters from the server that override
the defaults, a client uses those default values. Second, in its
interface independently to obtain configuration information
parameters for those separate interfaces.
+
+
+
+Droms [Page 21]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
3.7 When clients should use DHCP
A client SHOULD use DHCP to reacquire or verify its IP address and
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
- DHCP relaying agent whose address appears in 'giaddr'. If the
- 'giaddr' field is zero and the 'ciaddr' field is nonzero, then the
- server should unicast the packet to the address in 'ciaddr'. If
- 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is set,
- then the server should broadcast the packet to 255.255.255.255. If
- the broadcast bit is not set and 'giaddr' is zero and 'ciaddr' is
- zero, then the server should unicast the packet to the client's
- hardware address and 'yiaddr' address.
+ BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
+ field is zero and the 'ciaddr' field is nonzero, then the server
+ unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
+ If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
+ set, then the server broadcasts DHCPOFFER and DHCPACK messages to
+
+
+
+Droms [Page 22]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
+ 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
+ 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
+ messages to the client's hardware address and 'yiaddr' address. In
+ all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
+ messages to 0xffffffff.
If the options in a DHCP message extend into the 'sname' and 'file'
fields, the 'option overload' option MUST appear in the 'options'
MAY provide an indication of retransmission attempts to the user as
an indication of the progress of the configuration process.
+
+
+
+Droms [Page 23]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
The 'xid' field is used by the client to match incoming DHCP messages
with pending requests. A DHCP client MUST choose 'xid's in such a
way as to minimize the chance of using an 'xid' identical to one used
to a DHCP client (i.e., not to a relay agent specified in the
'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
- an IP broadcast using an IP broadcast address (preferably
- 255.255.255.255) as the IP destination address and the link-layer
- broadcast address as 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 specified in the 'yiaddr' field and the
- link-layer address specified in the 'chaddr' field. If unicasting is
- not possible, the message MAY be sent as an IP broadcast using an IP
- broadcast address (preferably 255.255.255.255) as the IP destination
- address and the link-layer broadcast address as the link-layer
- destination address.
+ an IP broadcast using an IP broadcast address (preferably 0xffffffff)
+ as the IP destination address and the link-layer broadcast address as
+ 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
+ specified in the 'yiaddr' field and the link-layer address specified
+ in the 'chaddr' field. If unicasting is not possible, the message
+ MAY be sent as an IP broadcast using an IP broadcast address
+ (preferably 0xffffffff) as the IP destination address and the link-
+ layer broadcast address as the link-layer destination address.
+
+
+
+
+
+
+Droms [Page 24]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
4.2 DHCP server administrative controls
identifier' in all subsequent messages, and the server MUST use that
identifier to identify the client. If the client does not provide a
'client identifier' option, the server MUST use the contents of the
- 'chaddr' field to identify the client. It is crucial for DHCP clients
- to use unique identifiers in the 'client identifier' option. Use of
+ '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 is attached in the 'client identifier' option. Use of
'chaddr' as the client's unique identifier may cause unexpected
results, as that identifier may be associated with a hardware
interface that could be moved to a new client. Some sites may choose
to select directly the 'vendor class identifier' and 'user class
identifier' values.
+
+
+
+Droms [Page 25]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
4.3 DHCP server behavior
A DHCP server processes incoming DHCP messages from a client based on
refuse to allocate an address to a particular client even though free
addresses are available.
- While not required for correct operation of DHCP, the server SHOULD
- not reuse the selected network address before the client responds to
- the server's DHCPOFFER message. The server may choose to record the
- address as offered to the client.
+
+
+
+Droms [Page 26]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- -------
Table 3: Fields and options used by DHCP servers
+
+
+Droms [Page 27]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
+ While not required for correct operation of DHCP, the server SHOULD
+ NOT reuse the selected network address before the client responds to
+ the server's DHCPOFFER message. The server may choose to record the
+ address as offered to the client.
+
The server must also choose an expiration time for the lease, as
follows:
o Parameters requested by the client, according to the following
rules:
+
+
+
+
+
+Droms [Page 28]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
-- IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value
in an appropriate option in the 'option' field, ELSE
A DHCPREQUEST message may come from a client responding to a
DHCPOFFER message from a server, from a client verifying a previously
allocated IP address or from a client extending the lease on a
+
+
+
+Droms [Page 29]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
network address. If the DHCPREQUEST message contains a 'server
identifier' option, the message is in response to a DHCPOFFER
message. Otherwise, the message is a request to verify or extend an
'server identifier' MUST NOT be filled in, 'requested IP address'
option MUST be filled in with client's notion of its previously
- assigned address. ciaddr MUST be zero. The client is seeking to
+ assigned address. 'ciaddr' MUST be zero. The client is seeking to
verify a previously allocated, cached configuration. Server SHOULD
send a DHCPNAK message to the client if the 'requested IP address'
is incorrect, or is on the wrong network.
Determining whether a client in the INIT-REBOOT state is on the
correct network is done by examining the contents of 'giaddr', the
'requested IP address' option, and a database lookup. If the DHCP
+
+
+
+Droms [Page 30]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
server detects that the client is on the wrong net (i.e., the
result of applying the local subnet mask or remote subnet mask (if
'giaddr' is not zero) to 'requested IP address' option value
behavior is necessary for peaceful coexistence of non-communicating
DHCP servers on the same wire.
- If 'ciaddr' is not set in the DHCPREQUEST message, the server
- SHOULD set the broadcast bit in the DHCPNAK message. DHCPNAK is
- broadcast to ensure that clients that may have an incorrect notion
- of subnet mask or have not yet configured a network address (in
- INIT-REBOOT state) will receive the DHCPNAK.
-
- If 'ciaddr' is set in the DHCPREQUEST message, then the client is
- configured to use the address and can respond to ARP requests
- messages, so the DHCPNAK should be unicast (since it may be on a
- remote subnet). Typically, this case occurs when the client's
- clock is much slower than the server's clock and the client
- believes it still has a valid lease even though the lease has
- actually expired.
-
- If 'ciaddr' is not set in the DHCPREQUEST message, the server
- SHOULD set the broadcast bit in the DHCPNAK message. DHCPNAK is
- broadcast to ensure that clients that may have an incorrect notion
- of subnet mask or have not yet configured a network address (in
- INIT-REBOOT state) will receive the DHCPNAK.
-
- If 'ciaddr' is set in the DHCPREQUEST message, then the client is
- configured to use the address and can respond to ARP requests
- messages, so the DHCPNAK should be unicast (since it may be on a
- remote subnet). Typically, this case occurs when the client's
- clock is much slower than the server's clock and the client
- believes it still has a valid lease even though the lease has
- actually expired.
+ If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on the
+ same subnet as the server. The server MUST broadcast the DHCPNAK
+ message to the 0xffffffff broadcast address because the client may
+ not have a correct network address or subnet mask, and the client
+ may not be answering ARP requests.
+
+ If 'giaddr' is set in the DHCPREQUEST message, the client is on a
+ different subnet. The server MUST set the broadcast bit in the
+ DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
+ client, because the client may not have a correct network address
+ or subnet mask, and the client may not be answering ARP requests.
o DHCPREQUEST generated during RENEWING state:
option MUST NOT be filled in, 'ciaddr' MUST be filled in with
client's IP address. In this situation, the client is completely
configured, and is trying to extend its lease. This message MUST be
+
+
+
+Droms [Page 31]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
broadcast to the 0xffffffff IP broadcast address. The DHCP server
SHOULD check 'ciaddr' for correctness before replying to the
DHCPREQUEST.
4.3.3 DHCPDECLINE message
- If the server receives a DHCPDECLINE message, the client has
- discovered through some other means that the suggested network
- address is already in use. The server MUST mark the network
- address as not available and SHOULD notify the local system
- administrator of a possible configuration problem.
+ If the server receives a DHCPDECLINE message, the client has
+ discovered through some other means that the suggested network
+ address is already in use. The server MUST mark the network address
+ as not available and SHOULD notify the local system administrator of
+ a possible configuration problem.
4.3.4 DHCPRELEASE message
- Upon receipt of a DHCPRELEASE message, the server marks the network
- address as not allocated. The server SHOULD retain a record of the
- client's initialization parameters for possible reuse in response
- to subsequent requests from the client.
+ Upon receipt of a DHCPRELEASE message, the server marks the network
+ address as not allocated. The server SHOULD retain a record of the
+ client's initialization parameters for possible reuse in response to
+ subsequent requests from the client.
4.3.5 DHCPINFORM message
- The server responds to a DHCPINFORM message by sending a DHCPACK
- message directly to the address given in the 'ciaddr' field of the
- DHCPINFORM message. The server SHOULD NOT send a lease expiration
- time to the client and SHOULD NOT fill in 'yiaddr'. The server
- includes other parameters in the DHCPACK message as defined in
- section 4.3.1.
+ The server responds to a DHCPINFORM message by sending a DHCPACK
+ message directly to the address given in the 'ciaddr' field of the
+ DHCPINFORM message. The server SHOULD NOT send a lease expiration
+ time to the client and SHOULD NOT fill in 'yiaddr'. The server
+ includes other parameters in the DHCPACK message as defined in
+ section 4.3.1.
4.3.6 Client messages
- Table 4 details the differences between messages from clients in
- various states.
+ Table 4 details the differences between messages from clients in
+ various states.
+
+
+
+
- ---------------------------------------------------------------------
- | |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
- ---------------------------------------------------------------------
- |broad/unicast |broadcast |broadcast |unicast |broadcast |
- |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
- |requested-ip |MUST |MUST |MUST NOT |MUST NOT |
- |ciaddr |zero |zero |IP address |IP address|
- ---------------------------------------------------------------------
- Table 4: Client messages from different states
+
+
+
+
+
+
+
+Droms [Page 32]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
+ ---------------------------------------------------------------------
+ | |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
+ ---------------------------------------------------------------------
+ |broad/unicast |broadcast |broadcast |unicast |broadcast |
+ |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
+ |requested-ip |MUST |MUST |MUST NOT |MUST NOT |
+ |ciaddr |zero |zero |IP address |IP address|
+ ---------------------------------------------------------------------
+
+ Table 4: Client messages from different states
4.4 DHCP client behavior
section corresponds to the abbreviated configuration procedure
described in section 3.2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms [Page 33]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
-------- -------
| | +-------------------------->| |<-------------------+
| INIT- | | +-------------------->| INIT | |
----------
Figure 5: State-transition diagram for DHCP clients
+
+
+
+
+
+
+Droms [Page 34]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
4.4.1 Initialization and allocation of network address
The client begins in INIT state and forms a DHCPDISCOVER message.
over which the client collects messages and the mechanism used to
select one DHCPOFFER are implementation dependent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms [Page 35]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
----- ------------ ----------- -----------
'hops' 0 0 0
'xid' selected by client 'xid' from server selected by
DHCPOFFER message client
- 'secs' (opt.) (opt.) 0
+ 'secs' 0 or seconds since 0 or seconds since 0
+ DHCP process started DHCP process started
'flags' Set 'BROADCAST' Set 'BROADCAST' 0
flag if client flag if client
requires broadcast requires broadcast
reply reply
- 'ciaddr' DHCPDISCOVER: 0 or client's client's network
- 0 or client's network address address
- netwrk address (BOUND/RENEW/REBIND) (DHCPRELEASE only)
- (BOUND/RENEW/REBIND)
- DHCPINFORM: client's
- network address
+ 'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
+ client's network address client's network
+ network address (BOUND/RENEW/REBIND) address
+ (DHCPINFORM) (DHCPRELEASE)
'yiaddr' 0 0 0
'siaddr' 0 0 0
'giaddr' 0 0 0
IP address lease time MAY MAY MUST NOT
(DISCOVER)
MUST NOT
+
+
+
+Droms [Page 36]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
(INFORM)
Use 'file'/'sname' fields MAY MAY MAY
DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
message. The client records the lease expiration time as the sum of
the time at which the original request was sent and the duration of
- the lease from the DHCPOFFER message. The client SHOULD perform a
+ the lease from the DHCPACK message. The client SHOULD perform a
check on the suggested address to ensure that the address is not
already in use. For example, if the client is on a network that
supports ARP, the client may issue an ARP request for the suggested
message. The client may request specific configuration parameters by
including the 'parameter request list' option. The client generates
and records a random transaction identifier and inserts that
+
+
+
+Droms [Page 37]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
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 DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
messages, unless the client knows the address of a DHCP server. The
client unicasts DHCPDECLINE and DHCPRELEASE messages to the server.
+
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
DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
The client may also use unicast to send DHCPINFORM messages to a
known DHCP server. If the client receives no response to DHCP
+
+
+
+Droms [Page 38]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
messages sent to the IP address of a known DHCP server, the DHCP
client reverts to using the IP broadcast address.
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
+
+
+
+Droms [Page 39]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
set by the network administrator. The server SHOULD return T1 and
T2, and their values SHOULD be adjusted from their original values to
take account of the time remaining on the lease.
- In both RENEWING and REBINDING state, 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
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
[6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
+
+
+
+Droms [Page 40]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
Communications Review), 20(4):50--59, 1990.
[7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
June 1981.
[21] Wimer, W., "Clarifications and Extensions for the Bootstrap
+
+
+
+Droms [Page 41]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
Protocol", RFC 1542, Carnegie Mellon University, October 1993.
6. Security Considerations
Phone: (717) 524-1145
EMail: droms@bucknell.edu
- This document will expire on March 31, 1996.
+ This document will expire on May 30, 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms [Page 42]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
A. Host Configuration Parameters
MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
RD = Router Discovery (RFC 1256, Proposed Standard)
-B. Changes to draft-ietf-dhc-dhcp-02.txt:
+
+
+Droms [Page 43]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
+B. Changes to draft-ietf-dhc-dhcp-0[2-5].txt:
* Changed 'host' to 'client' throughout when explicitly referencing a
DHCP client.
how the server probes a reused address before allocating it to a DHCP
client.
+* In table 5, corrected description of values to be inserted in
+ 'ciaddr' field in DHCPDISCOVER and DHCPINFORM messages.
+
* Changed and added text as suggested by Glenn Stump for separate
'vendor class' and 'user class' options:
- Section 4.3.1, changed last paragraph to include vendor and user
class identifiers.
- - Modified table 5 to include both vendor and uesr class identifiers.
+ - Modified table 5 to include both vendor and user class identifiers.
+
+* Changed two incorrect (and duplicated) paragraphs in the second
+ bulleted item in section 4.3.2 to correctly describe when a server
+ broadcasts a DHCPNAK and when a server sets the broadcast bit in a
+ DHCPNAK.
+
+* Eliminated blank line in section 1.1
+
+* Changed fourth bullet item in list in section 1.5 to "Allow
+ automated ..." to avoid confusion with previous definition of
+ "automatic".
+
+
+
+
+Droms [Page 44]
+\f
+DRAFT Dynamic Host Configuration Protocol November 1995
+
+
+* Added sentence to last paragraph of section 2 clarifying that a
+ 'client' identifier MUST be unique to the client within its subnet.
+
+* Added "using the 'client identifier' option." to the last sentence
+ of the second paragraph of section 2.1.
+
+* Omitted "(i.e., 'ciaddr' == 0)" from numbered item 2 in section 3.1
+ as it was misleading (server may not always be allocating a new
+ address when 'ciaddr' == 0).
+
+* Fixed numbered item 2 in section 3.2 to match section 4.3.2, in
+ which the server is required to broadcast a DHCPNAK when 'giaddr' ==
+ 0.
+
+* Fixed the fourth and ninth paragraphs of section 4.1 to show that a
+ server always broadcasts DHCPNAK messages when 'giaddr' == 0.
+
+* Fixed third paragraph of section 4.2 to clarify that a client
+ identifier must be unique within the subnet.
+
+* Fixed typo - missing end of sentence in section 4.1, fourth
+ paragraph.
+
+* In section 2, corrected reference to RFC 1533 to RFC 1542.
+
+* In section 4.4.1, last paragraph, corrected computation of lease
+ time to use time from DHCPACK message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms [Page 45]
+\f
projects / thirdparty / dhcp.git / commitdiff
