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