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