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: host-conf@sol.bucknell.edu. 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 stevea@i88.isc.com David Borman dab@cray.com Scott Bradner sob@harvard.edu Lida Carrier lida@apple.com Ralph Droms droms@bucknell.edu Robert Gilligan gilligan@eng.sun.com Philip Karn karn@thumper.bellcore.com Holly Knight holly@apple.com Philip Koch philip.koch@dartmouth.edu Joshua Littlefield josh@cayman.com Greg Minshall minshall@wc.novell.com Bill Rust wjr@ftp.com Tom Sandoski tom@concert.net Richard Smith smiddy@pluto.dss.com Glenn Trewitt trewitt@nsl.pa.dec.com John Veizades veizades@apple.com A. Lee Wade wade@discovery.arc.nasa.gov Jesse Walker walker@eider.enet@decpa.dec.com Carol Ward cward@spot.colorado.edu Jonathan Wenocur jhw@shiva.com Kathy Wilde wilde@decvax.dec.com Walter Wimer walter.wimer@andrew.cmu.edu 3