+
Network Working Group R. Droms
INTERNET DRAFT Bucknell University
-Obsoletes: draft-ietf-dhc-dhcp-06.txt May 1996
- Expires November 1996
+Obsoletes: draft-ietf-dhc-dhcp-08.txt December 1996
+ Expires June 1997
Dynamic Host Configuration Protocol
- <draft-ietf-dhc-dhcp-07.txt>
+ <draft-ietf-dhc-dhcp-09.txt>
Status of this memo
Droms [Page 1]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
2.1 Configuration parameters repository . . . . . . . . . . . . . 11
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
- 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . .42
- A. Host Configuration Parameters . . . . . . . . . . . . . . . .43
+ 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .40
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .41
+ 7. Security Considerations. . . . . . . . . . . . . . . . . . . .42
+ 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .43
+ A. Host Configuration Parameters . . . . . . . . . . . . . . . .44
List of Figures
-
Droms [Page 2]
\f
-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
Droms [Page 3]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
BOOTP specification [7, 21] and to allow interoperability of existing
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
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
- minimum lease time restriction has been removed. Finally, many
- editorial changes have been made to clarify the text as a result of
- experience gained in DHCP interoperability tests.
+ "vendor" classes as defined in sections 4.2 and 4.3. The minimum
+ lease time restriction has been removed. Finally, many editorial
+ changes have been made to clarify the text as a result of experience
+ gained in DHCP interoperability tests.
1.2 Related Work
Droms [Page 4]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
discovery algorithm can determine the MTU of an arbitrary internet
Droms [Page 5]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
o "SHOULD"
Droms [Page 6]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
o "binding"
Droms [Page 7]
\f
-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
Droms [Page 8]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
0 1 2 3
Droms [Page 9]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
DHCP clarifies the interpretation of the 'siaddr' field as the
Droms [Page 10]
\f
-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
Droms [Page 11]
\f
-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-
Droms [Page 12]
\f
-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
Droms [Page 13]
\f
-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
Droms [Page 14]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
Server Client Server
Droms [Page 15]
\f
-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
Droms [Page 16]
\f
-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
Droms [Page 17]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
DHCPREQUEST message.
check that the client's network address is already in use; the
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
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]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
- Figure 4: Timeline diagram of messages exchanged between DHCP
- client and servers when reusing a previously allocated
- network address
-
+ 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
the same subnet as the server. The server MUST
DHCPREQUEST message four times, for a total delay of 60 seconds,
before restarting the initialization procedure. If the client
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]
\f
-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
moving to BOUND state in the client state transition diagram shown
in figure 5.
to obtain other local configuration parameters. Servers receiving a
DHCPINFORM message construct a DHCPACK message with any local
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]
\f
-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
of the DHCPINFORM message.
be ignored by servers, and multiple servers may, therefore, not
return identical values for some options. The 'requested IP address'
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]
\f
-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.
If a server receives a DHCPREQUEST message with an invalid 'requested
be the 'end' option.
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]
\f
-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
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
its IP address must have the source address field in the IP header
set to 0.
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
by the 'options overload' option) MUST begin with the first octet of
+
+
+
+Droms [Page 23]
+\f
+DRAFT Dynamic Host Configuration Protocol December 1996
+
+
the field, MUST be terminated by an 'end' option, and MUST be
followed by 'pad' options to fill the remainder of the field. Any
individual option in the 'options', 'sname' and 'file' fields MUST be
DHCP clients are responsible for all message retransmission. The
client MUST adopt a retransmission strategy that incorporates a
-
-
-
-Droms [Page 23]
-\f
-DRAFT Dynamic Host Configuration Protocol May 1996
-
-
randomized exponential backoff algorithm to determine the delay
between retransmissions. The delay between retransmissions SHOULD be
chosen to allow sufficient time for replies from the server to be
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
unicast delivery. The IP destination address (in the IP header) is
set to the DHCP 'yiaddr' address and the link-layer destination
+
+
+
+Droms [Page 24]
+\f
+DRAFT Dynamic Host Configuration Protocol December 1996
+
+
address is set to the DHCP 'chaddr' address. Unfortunately, some
client implementations are unable to receive such unicast IP
datagrams until the implementation has been configured with a valid
clarifications document discusses the ramifications of the use of the
BROADCAST bit [21].
-
-
-
-Droms [Page 24]
-\f
-DRAFT Dynamic Host Configuration Protocol May 1996
-
-
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
'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
network administrator.
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
- server to examine the 'user class identifier' to determine which
- printer server address to return in a DHCPOFFER or DHCPACK message.
+
+
+
+Droms [Page 25]
+\f
+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
client with its lease. The client MAY choose to explicitly provide
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
-
-
-
-Droms [Page 25]
-\f
-DRAFT Dynamic Host Configuration Protocol May 1996
-
-
results, as that identifier may be associated with a hardware
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
DHCP clients are free to use any strategy in selecting a DHCP server
among those from which the client receives a DHCPOFFER message. The
client implementation of DHCP SHOULD provide a mechanism for the user
- to select directly the 'vendor class identifier' and 'user class
- identifier' values.
+ to select directly the 'vendor class identifier' values.
4.3 DHCP server behavior
a server. The remainder of this section describes the action of the
DHCP server for each possible incoming message.
+
+
+
+Droms [Page 26]
+\f
+DRAFT Dynamic Host Configuration Protocol December 1996
+
+
4.3.1 DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE
-
-
-Droms [Page 26]
-\f
-DRAFT Dynamic Host Configuration Protocol May 1996
-
-
o The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE
o IF the client has not requested a specific lease in the
DHCPDISCOVER message and the client already has an assigned network
address, the server returns the lease expiration time previously
+
+
+
+Droms [Page 27]
+\f
+DRAFT Dynamic Host Configuration Protocol December 1996
+
+
assigned to that address (note that the client must explicitly
request a specific lease to extend the expiration time on a
previously assigned address), ELSE
-Droms [Page 27]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms [Page 28]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
Field DHCPOFFER DHCPACK DHCPNAK
Message SHOULD SHOULD SHOULD
Client identifier MUST NOT MUST NOT MAY
Vendor class identifier MAY MAY MAY
- User class identifier MUST MUST MAY
Server identifier MUST MUST MUST
Maximum message size MUST NOT MUST NOT MUST NOT
All others MAY MAY MUST NOT
-Droms [Page 28]
+
+Droms [Page 29]
\f
-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
-Droms [Page 29]
+Droms [Page 30]
\f
-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
- by the contents of the 'vendor class identifier' or 'user class
- identifier' options in the DHCPDISCOVER or DHCPREQUEST message),
+ by the contents of the 'vendor class identifier'
+ option in the DHCPDISCOVER or DHCPREQUEST message),
e.g., as configured by the network administrator; the parameters
- MUST be identified by an exact match between the client's vendor and
- user class identifiers and the client's classes identified in the
+ MUST be identified by an exact match between the client's vendor
+ class identifiers and the client's classes identified in the
server,
o Parameters with non-default values on the client's subnet.
- The server MAY choose to return the 'vendor class identifier' and
- MUST return the 'user class identifier' used to determine the
- parameters in the DHCPOFFER message to assist the client in selecting
- which DHCPOFFER to accept. The server inserts the 'xid' field from
- the DHCPDISCOVER message into the 'xid' field of the DHCPOFFER
- message and sends the DHCPOFFER message to the requesting client.
+ The server MAY choose to return the 'vendor class identifier' used to
+ determine the parameters in the DHCPOFFER message to assist the
+ client in selecting which DHCPOFFER to accept. The server inserts
+ the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
+ the DHCPOFFER message and sends the DHCPOFFER message to the
+ requesting client.
4.3.2 DHCPREQUEST message
-Droms [Page 30]
+Droms [Page 31]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
may choose to try another DHCPDISCOVER message. Therefore, the
-Droms [Page 31]
+Droms [Page 32]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
o DHCPREQUEST generated during RENEWING state:
-Droms [Page 32]
+Droms [Page 33]
\f
-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
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.
+ DHCPINFORM message. The server MUST 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
-Droms [Page 33]
+
+Droms [Page 34]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
-------- -------
-Droms [Page 34]
+Droms [Page 35]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
4.4.1 Initialization and allocation of network address
-Droms [Page 35]
+Droms [Page 36]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
-Droms [Page 36]
+Droms [Page 37]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
(INFORM)
DHCPINFORM DHCPRELEASE
Client identifier MAY MAY MAY
Vendor class identifier MAY MAY MUST NOT
- User class identifier MAY MAY MUST NOT
Server identifier MUST NOT MUST (after MUST
SELECTING)
MUST NOT (after
4.4.2 Initialization with known network address
The client begins in INIT-REBOOT state and sends a DHCPREQUEST
- 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
+ message. The client MUST insert its known network address as a
+ 'requested IP address' option in the DHCPREQUEST message. The client
+ may request specific configuration parameters by including the
+ 'parameter request list' option. The client generates and records a
-Droms [Page 37]
+Droms [Page 38]
\f
-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
- 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.
+ 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
client's DHCPREQUEST message arrives from any server, the client is
messages, unless the client knows the address of a DHCP server. The
client unicasts DHCPRELEASE messages to the server. Because the
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
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]
\f
-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
known DHCP server. If the client receives no response to DHCP
messages sent to the IP address of a known DHCP server, the DHCP
-
-Droms [Page 39]
+Droms [Page 40]
\f
-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
DHCPRELEASE message to the server. Note that the correct operation
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]
+\f
+DRAFT Dynamic Host Configuration Protocol December 1996
+
+
+6. References
[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
1983.
[5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
(DRARP)", Work in Progress.
-
-
-
-Droms [Page 40]
-\f
-DRAFT Dynamic Host Configuration Protocol May 1996
-
-
[6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
Communications Review), 20(4):50--59, 1990.
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
+
+
+
+
+Droms [Page 42]
+\f
+DRAFT Dynamic Host Configuration Protocol December 1996
+
+
[14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
June 1981.
-
-
-Droms [Page 41]
-\f
-DRAFT Dynamic Host Configuration Protocol May 1996
-
-
[21] Wimer, W., "Clarifications and Extensions for the Bootstrap
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
insecure. Furthermore, DHCP is generally intended to make
claim all resources for itself, thereby denying resources to
legitimate clients.
-7. Author's Address
+
+
+
+Droms [Page 43]
+\f
+DRAFT Dynamic Host Configuration Protocol December 1996
+
+
+8. Author's Address
Ralph Droms
Computer Science Department
-Droms [Page 42]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms [Page 44]
\f
-DRAFT Dynamic Host Configuration Protocol May 1996
+DRAFT Dynamic Host Configuration Protocol December 1996
A. Host Configuration Parameters
-Droms [Page 43]
-\f
+Droms [Page 45]
+
projects / thirdparty / dhcp.git / commitdiff
