home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
dhc
/
dhc-minutes-91jul.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
10KB
|
280 lines
CURRENT_MEETING_REPORT_
Reported by Ralph Droms/Bucknell
DHC Minutes
Modifications and Extensions to DHCP
The Working Group agreed to the following changes and additions to DHCP.
The DHCP Internet Draft will be edited to reflect these changes.
Changes to Protocol
The client--server protocol has been changed slightly, so that the
client first broadcasts a message to locate available DHCP servers, and
then selects one of the responding servers from which the client obtains
its configuration parameters.
Protocol Messages
Corresponding to the changes to the protocol summarized in section 1.1,
the DHCP messages have been redefined as shown in table 1.
Client--Server Interaction
1. Client broadcasts DHCPDISCOVER on local physical subnet.
DHCP/BOOTP relay agents pass the broadcast on to DHCP servers not
on the same physical subnet.
2. Servers respond with DHCPOFFER message with all configuration
parameters including network address. 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. The DHCPOFFER message is ``unicast'' to
the client (using the BOOTP relay agent if necessary).
3. Client receives DHCPOFFER message from server. Client may choose
to wait for multiple responses. Client chooses one server from
which to request configuration parameters, based on offered
configuration parameters in the DHCPOFFER messages. Client
broadcasts a DHCPREQUEST message, specifying the desired server and
desired network address in vendor extension fields. This
DHCPREQUEST message is broadcast and relayed through BOOTP relay
agents. Any DHCP/BOOTP relay agents must ensure that any messages
from this client are forwarded to the same set of DHCP servers to
ensure that the DHCPREQUEST message reaches the selected DHCP
server.
The client times out and retransmits the DHCPDISCOVER message if
the client receives no DHCPOFFER messages.
1
___Message_________________________________Use__________________________
DHCPDISCOVER Client broadcast to locate available
servers.
DHCPOFFER Server to client in response to DHCPDISCOVER
with offer of configuration parameters.
DHCPREQUEST Client broadcast to servers requesting
offered parameters from one server and
implicitly declining offers from all others.
DHCPACK Server to client with configuration
parameters, including committed network
address.
DHCPNAK Server to client declining request for
configuration parameters (e.g., requested
network address already allocated).
DHCPDECLINE Client to server indicating configuration
parameters (e.g., network address) invalid.
DHCPRELEASE Client to server relinquishing network
address and cancelling remaining lease.
Table 1: DHCP Messages
4. Servers receive the DHCPREQUEST broadcast from the client. The
servers not selected in the DHCPREQUEST message use the message as
notification that the client has declined that server's offer. The
server selected in the DHCPREQUEST commits the binding for the
client to persistent storage and responds with a DHCPACK message
containing the configuration parameters for the requesting client.
The server inserts a unique lease identification cookie as a vendor
extension.
If the selected server is unable to satisfy the DHCPREQUEST (e.g.,
the requested network address has been allocated), the server
responds with a DHCPNAK.
5. Client receives the DHCPACK with configuration parameters. The
client performs a last minute check on the parameters (e.g., ARP
for allocated network address), and notes the duration of the lease
and the lease identification cookie specified in the DHCPACK
message. At this point, the client is configured.
If the client detects a problem with the parameters in the DHCPACK
message, the client sends a DHCPDECLINE message to the server and
restarts the configuration process.
2
_________Extension_________Tag________Values________Length_
DHCP message type 51 1=DHCPDISCOVER [3]
2=DHCPOFFER
3=DHCPREQUEST
4=DHCPDECLINE
5=DHCPACK
6=DHCPNAK
7=DHCPRELEASE
Lease identifier cookie 52 address [6]
Server identifier 53 address [6]
Parameter request vector 54 256 bit (32 octet) [34]
vector
Parameter request list 55 n parameter tags [n+2]
Table 2: New Vendor Extensions
If the client receives a DHCPNAK message, the client restarts the
configuration process.
The client times out and retransmits the DHCPREQUEST message if the
client receives neither a DHCPACK or a DHCPNAK message.
6. A client may choose to relinquish its lease on a network address by
sending a DHCPRELEASE to the server. The client identifies the
lease to be released with the lease identification cookie.
New Vendor Extensions
The modifications to DHCP require some new vendor extensions, as listed
in table 2.
Use of Vendor Extensions
A client can fill in vendor extensions in a DHCPDISCOVER and DHCPREQUEST
to supply hints or request specific values from a server. For example,
the client can fill in the 'IP address' vendor extensions to suggest a
remembered network address The server fills in vendor extensions in
DHCPDISCOVER and DHCPACK messages to supply specific configuration
values to the client.
A client can also request specific configuration parameters without
supplying hints through the ``parameter request vector'' and ``parameter
request list'' vendor extensions. In the parameter request vector, a
one bit in position n in the vector represents an explicit request for
the vendor extensions parameter with tag n. The parameter request list
3
is a list of vendor extension tags explicitly requested by the client.
Lease Durations and Clock Drift
The algorithm for lease duration interpretation given in subsection 6.1
of the DHCP Internet Draft is correct, assuming the client and server
clocks are stable relative to each other. If there is drift between the
two clocks, the server may still consider the lease expired before the
client does. To compensate, the server may return a different lease
duration to the client than the server commits to its local database of
client information.
Lease Renewal Times
The client attempts to renew its lease from the allocating server
beginning at time T1and from any available server at time T2. Times T1
and T2 are configurable by the server through vendor extensions.
T1defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
duration_of_lease).
XID Field
The XID field must be interpreted by the server relative to individual
clients, not as a globally unique value.
Retransmission
The client drives all retransmissions of the protocol. The protocol
document still needs explicit descriptions of retransmission and
exponential backoff algorithms.
``ciaddr'' (Clarification)
The ``ciaddr'' field is to be filled in by the client only if the client
has explicit knowledge of its network address. The client can supply a
hint or a preferred network address through the IP address vendor
extension.
If a server receives a DHCPDISCOVER or DHCPREQUEST message with an
invalid ``ciaddr'', the server silently discards the message.
Use of DHCP in Hosts with Multiple Interfaces
A host with multiple network interfaces must use DHCP through each
interface independently to obtain configuration information parameters
for those separate interfaces.
DHCP and BOOTP Clients
Use of the vendor extensions defined in DHCP is not restricted to DHCP
clients and servers. Existing BOOTP clients and servers may choose to
use the newly defined vendor extensions. The one restriction is that
BOOTP clients MAY NOT use the ``DHCP client'' vendor extensions. Only
clients using DHCP may use the ``DHCP client'' vendor extension.
4
Implementations
Several members of the DHC Working Group indicated that they intend to
work on independent implementations of DHCP. Completion of at least one
of these implementations is expected before the Spring, 1992 IETF
meeting.
Future Work
Greg Minshall agreed to develop a definition of the DHCP server-server
protocol. Jesse Walker and Walt Wimer agreed to collaborate on the
definition of a MIB for DHCP servers.
Attendees
Steve Alexander stevea@i88.isc.com
Richard Basch basch@mit.edu
David Bridgham dab@asylum.sf.ca.us
Gregory Bruell gob@shiva.com
Richard Cogger rhx@cornellc.cit.cornell.edu
Steve Deering deering@xerox.com
Ralph Droms droms@bucknell.edu
Karen Frisa karen.frisa@andrew.cmu.edu
Robert Gilligan gilligan@eng.sun.com
Ron Jacoby rj@sgi.com
Douglas Kerr dougk@mtxinu.com
Michael Khalandovsky mlk@ftp.com
Holly Knight holly@apple.com
Nik Langrind nik@shiva.com
Joshua Littlefield josh@cayman.com
Greg Minshall minshall@wc.novell.com
William Nowicki nowicki@legato.com
Michael O'Dell mo@bellcore.com
Bradford Parker brad@cayman.com
Mark Saake saake@llnl.gov
Jesse Walker walker@eider.enet@decpa.dec.com
Jonathan Wenocur jhw@shiva.com
Walter Wimer walter.wimer@andrew.cmu.edu
John Wobus jmwobus@suvm.acs.syr.edu
5