Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/dhc/dhc-minutes-90dec.txt

Text File | 1993-02-17 | 6KB | 143 lines

CURRENT_MEETING_REPORT_


Reported by Ralph Droms/Bucknell

DHC Minutes

Agenda:

The Agenda centered on discussing details of the Dynamic Host
Configuration Protocol (DHCP). There are four components of the
Protocol:


  1. A client-server protocol (here, a ``client'' refers to a network
     host requesting initialization parameters).
  2. An algorithm for dynamic allocation of IP addresses by a server.
  3. A server-server protocol.
  4. A mechanism through which DHCP forwarding agents pass DHCP packets
     between clients and clients on different subnets.


All of the protocols and algorithms used by DHCP have been presented and
discussed at earlier Working Group meetings.  At this meeting, it was
decided that the protocol should be described in two RFCs:


   o One describing the interaction between a client and a single
     server.
   o A second describing the interaction between multiple servers
     providing replicated service.


Ralph Droms will complete an Internet Draft describing the client-server
protocol before the next IETF meeting; further study is required for the
server-server protocol and the Working Group has no deadline for
completion of an Internet Draft for that component of DHCP.

The following topics were discussed at the meeting:


   o The Working Group needs to specify in detail the behavior of DHCP
     forwarding agents, both for DHCP and for the Router Requirements
     RFC. Walt Wimer graciously agreed to take on the task of writing an
     appropriate specification.


                                   1






   o The client-server protocol is based on BOOTP (RFC951) and the
     defined vendor extensions (RFC1084).  DHCP retains the original
     format of BOOTP packets, and defines an additional set of vendor
     extension values.  An appendix to these minutes gives a list of
     proposed configuration parameters and vendor extension formats.
     This list is based on a list of configurable parameters taken from
     the RFCs by Steve Deering.  DHCP also retains the request-response
     format of BOOTP. DHCP is backward-compatible with BOOTP, so that
     DHCP servers can support BOOTP clients.

   o It is possible that a server response packet may require more than
     the 64 bytes specified for the vendor extension area in the BOOTP
     packet format.  Two solutions were proposed.  First, the BOOTP
     packet is only 320 bytes long, so the vendor extension area can be
     extended while keeping the BOOTP packet under 576 bytes.  As the
     client request packet specifies whether the request is a DHCP
     request, a server can maintain backward compatibility with BOOTP
     clients by restricting BOOTP responses to 64 bytes while extending
     the vendor extension area in DHCP responses.  Second, the server
     response may take multiple packets.  The client can detect a
     multiple packet response by matching the returned parameters with
     the original list of requested parameters; if not all of the
     requested parameters were supplied (presumably because of a lack of
     space in the response packet), the client will issue a second
     request for the remaining parameters.

   o One of the parameters to be supplied by a server may be a
     dynamically assigned IP address.  For the first RFC, each server is
     statically assigned a set of IP addresses for dynamic allocation.
     The addresses are managed according to the algorithm proposed by
     Jeff Mogul in his draft of June 22, 1990.  The second RFC will
     address the problem of dynamic reallocation of IP addresses among a
     cooperating collection of DHCP servers.

   o The issue of security was raised and it was suggested that DHCP
     security be discussed with the Security Working Group.  Scott
     Bradner and Ralph Droms held an informal ``in the hall'' meeting
     with Steve Crocker.  According to Steve, the current, surrounding
     infrastructure is sufficiently insecure that securing DHCP will not
     add to network security, The Working Group should remain aware of
     the security issue and DHCP should evolve to take advantage of new
     security mechanisms as they are added to the Internet
     infrastructure.


There is a mailing list for the use of the Working Group:
[e-mail].  An archive of traffic and other pertinent
documents can be accessed through anonymous ftp from sol.bucknell.edu
under directory dhcwg.

Attendees


                                   2






Steve Alexander          [e-mail]
David Borman             [e-mail]
Scott Bradner            [e-mail]
Lida Carrier             [e-mail]
Ralph Droms              [e-mail]
Robert Gilligan          [e-mail]
Philip Karn              [e-mail]
Holly Knight             [e-mail]
Philip Koch              [e-mail]
Joshua Littlefield       [e-mail]
Greg Minshall            [e-mail]
Bill Rust                [e-mail]
Tom Sandoski             [e-mail]
Richard Smith            [e-mail]
Glenn Trewitt            [e-mail]
John Veizades            [e-mail]
A. Lee Wade              [e-mail]
Jesse Walker             [e-mail]@decpa.dec.com
Carol Ward               [e-mail]
Jonathan Wenocur         [e-mail]
Kathy Wilde              [e-mail]
Walter Wimer             [e-mail]



                                   3