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          [email protected]
Richard Basch            [email protected]
David Bridgham           [email protected]
Gregory Bruell           [email protected]
Richard Cogger           [email protected]
Steve Deering            [email protected]
Ralph Droms              [email protected]
Karen Frisa              [email protected]
Robert Gilligan          [email protected]
Ron Jacoby               [email protected]
Douglas Kerr             [email protected]
Michael Khalandovsky     [email protected]
Holly Knight             [email protected]
Nik Langrind             [email protected]
Joshua Littlefield       [email protected]
Greg Minshall            [email protected]
William Nowicki          [email protected]
Michael O'Dell           [email protected]
Bradford Parker          [email protected]
Mark Saake               [email protected]
Jesse Walker             [email protected]@decpa.dec.com
Jonathan Wenocur         [email protected]
Walter Wimer             [email protected]
John Wobus               [email protected]



                                  5

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.