Editor's Note: Minutes received 12/7/92 CURRENT_MEETING_REPORT_ Reported by Ralph Droms/Bucknell Minutes of the Dynamic Host Configuration Working Group (DHC) The Dynamic Host Configuration Working Group met twice in Washington. In the first meeting, the Working Group reviewed the state of the protocol specification. Ralph Droms described several recent changes to the specification documents, made in response to the IESG's review. Comments about the changes were posted to the host-conf mailing list and are available from the list archive in sol.cs.bucknell.edu:dhcwg/host-conf-archive. Two additional issues not previously addressed by the IESG were raised by Philip Almquist in an ``in-the-hall'' meeting: DHCP must permit server to disallow access to network addresses by unauthorized clients, and DHCP servers should be able to provide client-specific network parameters; i.e., DHCP servers should not be required to provide the same parameters (e.g., DNS server) to all clients on a subnet. The Working Group approved of the changes to the specification documents. After several additional changes are completed, DHCP will be resubmitted to the IESG for consideration as a ``Proposed Standard''. There was a brief discussion of BOOTP/DHCP relay agent behavior relating to the insertion of the client's subnet mask in DHCP messages by the relay agent. The Group concluded that DHCP servers must be aware of the network topology and can, therefore, always determine the appropriate subnet mask for a DHCP message. Thus, there is no advantage in allowing relay agents to supply the subnet mask. The Group decided that BOOTP/DHCP relay agents are not allowed to insert a subet mask into BOOTP/DHCP messages. Walt Wimer will modify the BOOTP/DHCP relay agent document to reflect this decision. The Working Group also discussed backwards compatibility with the use of the `file' field in BOOTP. DHCP will continue to use the `file' field as in BOOTP (except where overridden by the `overload' option [op[tion code 48]). DHCP will also use `siaddr' to hold the address of the server the DHCP client is to contact for further configuration (e.g., a TFTP server from which the DHCP client may obtain a "boot file"). Wimer will modify the BOOTP clarification document and Droms will modify the DHCP specification to explicitly describe these uses of the `file' and `siaddr' fields. Next, the Working Group embarked on a lengthy discussion about the use options and the interpretation of some options as ``vendor-specific''. The concern is that some vendors may have difficulty in obtaining allocation of option numbers from IANA for options that are specific to that vendor. The proposal was to define a ``vendor identifier'' option, and a range of options as ``vendor-specific''. The ``vendor-specific'' options would then be interpreted based on the ``vendor identifier''. For example, if a client identified itself as a ``Bison Chip Computers'' client by including a ``vendor identifier'' option with value ``Bison 1 Chip Computers'', the ``vendor-specific'' options would then be interpreted according to ``Bison Chip Computers'' allocation of option values. Such a mechanism would give individual vendors freedom in allocating options as they desired without having to go to IANA for new options. The Working Group took the proposal for a ``vendor identifier'' and ``vendor-specific'' options under advisement. There was a counter-argument that fewer than 50 of the available 128 options have been used to date (128-254 are reserved for ``site-specific'' options), so that the ``vendor-specific'' option mechanism may not be necessary. Bob Gilligan suggested some modifications to Wimer's BOOTP/DHCP clarification document to explicitly describe the interactions between clients and servers in networks that may have both BOOTP and DHCP servers. In particular, DHCP servers must be configurable to disallow the automatic allocation of network addresses in networks where clients may receive responses from both BOOTP and DHCP servers. In its second meeting, the Working Group took up the issue of a server-server protocol to automate the replication and reallocation of network address bindings. Greg Minshall presented a specific proposal that would provide redundant allocation, redundant reacquisition of a previously allocated address and distributed extension of an existing lease. Greg also mentioned the use of SNMP as a configuration tool once DHCP has provided sufficient configuration to the client to allow operation of a transport protocol. Droms suggested that Deering's work in identifying all of the configurable parameters cited in the Host Requirements documents should be forwarded to the appropriate MIB working groups for their consideration. The Working Group concluded that DHCP should be kept as lightweight as possible, deferring to other configuration mechanisms such as SNMP and TFTP wherever possible. Attendees Steve Alexander stevea@i88.isc.com James Allard jallard@microsoft.com Richard Basch basch@mit.edu J. Nevil Brownlee nevil@aukuni.ac.uz Matthew Busche mtb@anchor.ho.att.com Michael Davison davison@fibercom.com Peter DiCamillo Peter_DiCamillo@brown.edu Jon Dreyer Jon.Dreyer@east.sun.com Ralph Droms droms@bucknell.edu Robert Gilligan Bob.Gilligan@eng.sun.com Nat Howard nrh@bellcore.com Ronald Jacoby rj@sgi.com Scott Kaplan scott@ftp.com Andrew Knutsen andrewk@sco.com Kent Malave kent@bach.austin.ibm.com Greg Minshall minshall@wc.novell.com 2 Drew Perkins ddp@andrew.cmu.edu Bradley Rhoades bdrhoades@mail.mmmg.com Fumio Teraoka tera@csl.sony.co.jp Jim Thompson jim@tadpole.com Walter Wimer walter.wimer@andrew.cmu.edu 3