mir/isc-dhcp
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/dhcp synced 2025-08-29 05:17:57 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Ted Lemon 1997-03-05 04:58:19 +00:00
parent 10552a7c8d
commit fddc1769f0
1 changed files with 281 additions and 168 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

449
doc/draft-ietf-dhc-dhcp-07.txt → doc/draft-ietf-dhc-dhcp-09.txt
View File

@ -1,12 +1,13 @@
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-08.txt December 1996
Expires November 1996 Expires June 1997
Dynamic Host Configuration Protocol Dynamic Host Configuration Protocol
<draft-ietf-dhc-dhcp-07.txt> <draft-ietf-dhc-dhcp-09.txt>
Status of this memo Status of this memo
@ -52,7 +53,7 @@ Table of Contents
Droms [Page 1] Droms [Page 1]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
2.1 Configuration parameters repository . . . . . . . . . . . . . 11 2.1 Configuration parameters repository . . . . . . . . . . . . . 11
@ -72,10 +73,11 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
@ -105,10 +107,9 @@ List of Tables
Droms [Page 2] Droms [Page 2]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 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
@ -164,7 +165,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 3] Droms [Page 3]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
BOOTP specification [7, 21] and to allow interoperability of existing BOOTP specification [7, 21] and to allow interoperability of existing
@ -178,10 +179,10 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
@ -220,7 +221,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 4] Droms [Page 4]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
discovery algorithm can determine the MTU of an arbitrary internet discovery algorithm can determine the MTU of an arbitrary internet
@ -276,7 +277,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 5] Droms [Page 5]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
o "SHOULD" o "SHOULD"
@ -332,7 +333,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 6] Droms [Page 6]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
o "binding" o "binding"
@ -388,7 +389,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 7] Droms [Page 7]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
o Guarantee that any specific network address will not be in o Guarantee that any specific network address will not be in
@ -444,7 +445,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 8] Droms [Page 8]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
0 1 2 3 0 1 2 3
@ -500,7 +501,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 9] Droms [Page 9]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
DHCP clarifies the interpretation of the 'siaddr' field as the DHCP clarifies the interpretation of the 'siaddr' field as the
@ -556,7 +557,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 10] Droms [Page 10]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 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
@ -612,7 +613,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 11] Droms [Page 11]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 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-
@ -668,7 +669,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 12] Droms [Page 12]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 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
@ -724,7 +725,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 13] Droms [Page 13]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 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
@ -780,7 +781,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 14] Droms [Page 14]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
Server Client Server Server Client Server
@ -836,7 +837,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 15] Droms [Page 15]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 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
@ -892,7 +893,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 16] Droms [Page 16]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
point, the client is configured. If the client detects that the point, the client is configured. If the client detects that the
@ -948,7 +949,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 17] Droms [Page 17]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
DHCPREQUEST message. DHCPREQUEST message.
@ -958,14 +959,6 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
@ -997,20 +990,26 @@ DRAFT Dynamic Host Configuration Protocol May 1996
| | | | | |
v v v v v v
Figure 4: Timeline diagram of messages exchanged between DHCP
client and servers when reusing a previously allocated
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
Droms [Page 18] Droms [Page 18]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
Figure 4: Timeline diagram of messages exchanged between DHCP NOT respond with a DHCPNAK unless the servers are using an explicit
client and servers when reusing a previously allocated mechanism to maintain coherency among the servers.
network address
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
@ -1055,16 +1054,16 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
previously allocated network address and configuration parameters
Droms [Page 19] Droms [Page 19]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
the retransmission algorithm, the client MAY choose to use the
previously allocated network address and configuration parameters
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.
@ -1111,16 +1110,16 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
in 'yiaddr' or including lease time parameters. The servers SHOULD
Droms [Page 20] Droms [Page 20]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
allocating a new address, checking for an existing binding, filling
in 'yiaddr' or including lease time parameters. The servers SHOULD
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.
@ -1167,16 +1166,16 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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 fills in the 'ciaddr' field only when correctly configured
Droms [Page 21] Droms [Page 21]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
client is verifying network parameters obtained previously. The
client fills in the 'ciaddr' field only when correctly configured
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
@ -1223,19 +1222,39 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
messages from a server to a client are sent to the 'DHCP client' port
Droms [Page 22] Droms [Page 22]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
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
(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.
The 'server identifier' field is used both to identify a DHCP server
in a DHCP message and as a destination address from clients to
servers. A server with multiple network addresses MUST be prepared
to to accept any of its network addresses as identifying that server
in a DHCP message. To accommodate potentially incomplete network
connectivity, a server MUST choose an address as a 'server
identifier' that, to the best of the server's knowledge, is reachable
from the client. For example, if the DHCP server and the DHCP client
are connected to the same subnet (i.e., the 'giaddr' field in the
message from the client is zero), the server SHOULD select the IP
address the server is using for communication on that subnet as the
'server identifier'. If the server is using multiple IP addresses on
that subnet, any such address may be used. If the server has
received a message through a DHCP relay agent, the server SHOULD
choose an address from the interface on which the message was
recieved as the 'server identifier' (unless the server has other,
better information on which to make its choice). DHCP clients MUST
use the IP address provided in the 'server identifier' option for any
unicast requests to the DHCP server.
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.
@ -1261,6 +1280,14 @@ DRAFT Dynamic Host Configuration Protocol May 1996
and MAY contain one or more 'pad' options to fill the options field. and MAY contain one or more 'pad' options to fill the options field.
The options in the 'sname' and 'file' fields (if in use as indicated The options in the 'sname' and 'file' fields (if in use as indicated
by the 'options overload' option) MUST begin with the first octet of by the 'options overload' option) MUST begin with the first octet of
Droms [Page 23]
DRAFT Dynamic Host Configuration Protocol December 1996
the field, MUST be terminated by an 'end' option, and MUST be the field, MUST be terminated by an 'end' option, and MUST be
followed by 'pad' options to fill the remainder of the field. Any followed by 'pad' options to fill the remainder of the field. Any
individual option in the 'options', 'sname' and 'file' fields MUST be individual option in the 'options', 'sname' and 'file' fields MUST be
@ -1279,14 +1306,6 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
Droms [Page 23]
DRAFT Dynamic Host Configuration Protocol May 1996
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
chosen to allow sufficient time for replies from the server to be chosen to allow sufficient time for replies from the server to be
@ -1317,6 +1336,14 @@ DRAFT Dynamic Host Configuration Protocol May 1996
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
unicast delivery. The IP destination address (in the IP header) is unicast delivery. The IP destination address (in the IP header) is
set to the DHCP 'yiaddr' address and the link-layer destination set to the DHCP 'yiaddr' address and the link-layer destination
Droms [Page 24]
DRAFT Dynamic Host Configuration Protocol December 1996
address is set to the DHCP 'chaddr' address. Unfortunately, some address is set to the DHCP 'chaddr' address. Unfortunately, some
client implementations are unable to receive such unicast IP client implementations are unable to receive such unicast IP
datagrams until the implementation has been configured with a valid datagrams until the implementation has been configured with a valid
@ -1335,14 +1362,6 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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].
Droms [Page 24]
DRAFT Dynamic Host Configuration Protocol May 1996
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
'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
@ -1373,12 +1392,17 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
DHCPREQUEST messages when determining the correct parameters for a
particular client. For example, an organization might have a
separate printer server for each type of end-user, requiring the DHCP Droms [Page 25]
server to examine the 'user class identifier' to determine which
printer server address to return in a DHCPOFFER or DHCPACK message. DRAFT Dynamic Host Configuration Protocol December 1996
of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
messages when determining the correct parameters for a particular
client.
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
@ -1391,14 +1415,6 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
Droms [Page 25]
DRAFT Dynamic Host Configuration Protocol May 1996
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
@ -1410,8 +1426,7 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
@ -1433,6 +1448,14 @@ DRAFT Dynamic Host Configuration Protocol May 1996
a server. The remainder of this section describes the action of the a server. The remainder of this section describes the action of the
DHCP server for each possible incoming message. DHCP server for each possible incoming message.
Droms [Page 26]
DRAFT Dynamic Host Configuration Protocol December 1996
4.3.1 DHCPDISCOVER message 4.3.1 DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the When a server receives a DHCPDISCOVER message from a client, the
@ -1448,13 +1471,6 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
Droms [Page 26]
DRAFT Dynamic Host Configuration Protocol May 1996
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
@ -1488,6 +1504,14 @@ DRAFT Dynamic Host Configuration Protocol May 1996
o IF the client has not requested a specific lease in the o IF the client has not requested a specific lease in the
DHCPDISCOVER message and the client already has an assigned network DHCPDISCOVER message and the client already has an assigned network
address, the server returns the lease expiration time previously address, the server returns the lease expiration time previously
Droms [Page 27]
DRAFT Dynamic Host Configuration Protocol December 1996
assigned to that address (note that the client must explicitly assigned to that address (note that the client must explicitly
request a specific lease to extend the expiration time on a request a specific lease to extend the expiration time on a
previously assigned address), ELSE previously assigned address), ELSE
@ -1506,9 +1530,42 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 27]
Droms [Page 28]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
Field DHCPOFFER DHCPACK DHCPNAK Field DHCPOFFER DHCPACK DHCPNAK
@ -1553,7 +1610,6 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
@ -1562,9 +1618,10 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 28]
Droms [Page 29]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
Once the network address and lease have been determined, the server Once the network address and lease have been determined, the server
@ -1618,27 +1675,27 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 29] Droms [Page 30]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 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
@ -1674,9 +1731,9 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 30] Droms [Page 31]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
may choose to try another DHCPDISCOVER message. Therefore, the may choose to try another DHCPDISCOVER message. Therefore, the
@ -1730,9 +1787,9 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 31] Droms [Page 32]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
o DHCPREQUEST generated during RENEWING state: o DHCPREQUEST generated during RENEWING state:
@ -1786,17 +1843,16 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 32] Droms [Page 33]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 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
@ -1842,9 +1898,10 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 33]
Droms [Page 34]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
-------- ------- -------- -------
@ -1898,9 +1955,9 @@ timers T1, T2 ------------ send DHCPREQUEST | |
Droms [Page 34] Droms [Page 35]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
4.4.1 Initialization and allocation of network address 4.4.1 Initialization and allocation of network address
@ -1954,9 +2011,9 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 35] Droms [Page 36]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE, Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
@ -2010,9 +2067,9 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 36] Droms [Page 37]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
(INFORM) (INFORM)
@ -2021,7 +2078,6 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
@ -2060,22 +2116,24 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
'parameter request list' option. The client generates and records a
Droms [Page 37] Droms [Page 38]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
identifier into the 'xid' field. The client records its own local random transaction identifier and inserts that identifier into the
time for later use in computing the lease expiration. The client 'xid' field. The client records its own local time for later use in
MUST NOT include a 'server identifier' in the DHCPREQUEST message. computing the lease expiration. The client MUST NOT include a
The client then broadcasts the DHCPREQUEST on the local hardware 'server identifier' in the DHCPREQUEST message. The client then
broadcast address to the 'DHCP server' UDP port. 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
@ -2114,19 +2172,19 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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.
Droms [Page 38] Droms [Page 39]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 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
@ -2177,10 +2235,9 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 40]
Droms [Page 39]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 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
@ -2211,7 +2268,35 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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.
Droms [Page 41]
DRAFT Dynamic Host Configuration Protocol December 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.
@ -2231,14 +2316,6 @@ DRAFT Dynamic Host Configuration Protocol May 1996
[5] Brownell, D, "Dynamic Reverse Address Resolution Protocol [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
(DRARP)", Work in Progress. (DRARP)", Work in Progress.
Droms [Page 40]
DRAFT Dynamic Host Configuration Protocol May 1996
[6] Comer, D., and R. Droms, "Uniform Access to Internet Directory [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
Communications Review), 20(4):50--59, 1990. Communications Review), 20(4):50--59, 1990.
@ -2266,6 +2343,15 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Specification", STD 13, RFC 1035, USC/Information Sciences Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987. Institute, November 1987.
Droms [Page 42]
DRAFT Dynamic Host Configuration Protocol December 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.
@ -2288,17 +2374,10 @@ DRAFT Dynamic Host Configuration Protocol May 1996
[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.
Droms [Page 41]
DRAFT Dynamic Host Configuration Protocol May 1996
[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
@ -2321,7 +2400,15 @@ DRAFT Dynamic Host Configuration Protocol May 1996
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
Droms [Page 43]
DRAFT Dynamic Host Configuration Protocol December 1996
8. Author's Address
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
@ -2346,9 +2433,35 @@ DRAFT Dynamic Host Configuration Protocol May 1996
Droms [Page 42]
Droms [Page 44]
DRAFT Dynamic Host Configuration Protocol May 1996 DRAFT Dynamic Host Configuration Protocol December 1996
A. Host Configuration Parameters A. Host Configuration Parameters
@ -2402,5 +2515,5 @@ Key:
Droms [Page 43] Droms [Page 45]