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