These minutes were compiled by Ralph Droms. Thanks to Barr Hibbs and
Mike Patrick for contributing their notes from the meeting.
The WG chair, Ralph Droms, opened the meeting with some administrative
details. The WG approved the user class option
<draft-ietf-dhc-userclass-02.txt> to go to WG last call. The chair
will make the announcement to the WG mailing list. There was some
question about whether the service location protocol draft
<draft-ietf-dhc-slp-02.txt> was ready for WG last call. The author,
Charlie Perkins, and the chair will resolve the status of that draft.
Sun is hosting "DHCP Connectathon 98" of DHCP clients and servers in San
Jose March 4-12. This event may be of interest to many WG members.
Last year 28 companies participated in Connectathon, and several
interoperability issues were resolved.
In response to questions about future developments in DHCP and DHCP
options, Droms proposed the formation of a "DHCP futures panel".
This panel would put together an internet draft with recommendations
on the development of new DHCP options and the effect those new
options on deployed clients and servers. Droms will announce the
formation of the panel to the WG mailing list, identify volunteers to
participate on the panel, and, with WG input, develop a charge and
timetable for the panel's activities.
DHCP-DNS interaction was discussed next. The current draft is stalled
due to lack of consensus about whether servers should be allowed to
perform DNS A record updates on behalf of the client. The WG did come
to consensus that some form of DNS security is required for dynamic
updates. The WG came to agreement that while the DHCP client SHOULD
be one to update the DNS A record, in certain specialized cases a DHCP
server MAY do so instead. In this case, the DHCP server MUST be sure
of both the name to use for the client, as well as the identity of the
client. Kim Kinnear agreed to develop examples of specific cases for
inclusion in the DHCP-DNS interaction draft. The WG also arranged for
interested parties to meet over lunch on Tuesday to continue the
discussion.
Baiju Patel from Intel proposed using DHCP to get IPSEC tunnel
configuration parameters. (draft-ietf-dhc-ipsec-dhcp-00.txt>. The
problem is determining the IP address to use inside the tunnel. The
proposed solution is to establish an IPSEC tunnel mode connection and
then use DHCP within the tunnel to obtain IP address and other
configuration parameters.
Bill Arbaugh from University of Pennsylvania presented a mechanism for
DHCP client-server authentication using public key exchange. The
details will be published in a draft soon. The mechanism provides
secure mobility and fits within the existing DHCP model. There may be
problems with carrying long certification keys in DHCP options and
packets.
Walt Lazear of MITRE reported on some work in configuring routers
using DHCP. The goal here is to automate the router configuration
process in dynamic, low-bandwidth networks. Lazear identified three
new options for router configuration: "autonomous system number", "BGP
neighbors list" and "served IP address ranges". The WG expressed
concern about the last option, but, in general, did not rule out
further consideration of these options.
Mike Patrick of Motorola reviewed changes included in the latest
revision of the agent options draft
<draft-ietf-dhc-agent-options-03.txt>. These changes reflect input
from the WG given after the Munich meeting.
Kim Kinnear of American Internet and Ralph Droms discussed the
inter-server protocol. Prior to the meeting, Droms polled several WG
members about the future of the inter-server protocol effort and the
perception of the requirements an inter-server protocol must meet.
This discussion contributed to the development of a new inter-server
protocol proposal <draft-ietf-dhc-failover-00.txt>. Kinnear led off
with a history of the inter-server protocol proposals and set the
current situation. There are now two proposals on the table: a
general-purpose protocol (Kinnear-Cole-Droms [KCD]) based on SCSP that
can accommodate multiple servers per address pool and support
automatic configuration of new servers, and a limited-purpose protocol
(Grabil-Dooley-Kapur-Droms [GDKD]) that provides hot-backup
reliability. The primary area of discussion was the possibility of
duplicate address allocation. The KCD protocol eliminates any
possibility of duplicate address allocation while the GDKD protocol
may allocate the same address to different hosts under certain
circumstances. The WG asked for a clear statement of purpose for the
GDKD protocol, and the WG will need to answer several questions before
deciding on one of these proposals:
* Are duplicate addresses never/rarely/sometimes allowable?
* Is automatic configuration of servers and server groups desirable?
* Is a single hot-backup sufficient or are multiple servers per
address pool required (e.g., for load sharing)?
Finally, Olafur Gudmundsson of TIS and Ralph Droms held a discussion
about DHCP authentication. Before this meeting, Droms had polled
several WG members about the authentication efforts. Droms and
Gudmundsson presented a proposal to develop a series of DHCP
authentication documents:
* DHCP authentication requirements document
* Authentication options definition (allowing for multiple
authentication algorithms)
* Separate drafts for each authentication algorithm
The WG expressed consensus to proceed with the development of these
documents.
DHC WG meeting - DHCPv6
-----------------------
These minutes were compiled by Ralph Droms.
Jim Bound (Digital) began the meeting with a report that the ngtrans
WG is specifying DHCP as a way to avoid the use of NATs in IPv4-IPv6
transition.
The remainder of the meeting on DHCPv6 focused on a review of changes
made to the DHCPv6 drafts in response to input from the WG meeting in
Munich. Charlie Perkins (Sun Microsystems) began by describing the
preferencing mechanism through which servers can control the choice of
server made by a client.
Mike Carney (Sun Microsystems) asked why the transaction ID is
specified as part of the binding. The consensus was that the
transaction ID need not be part of the binding and will be removed in
the next draft.
Several other issues, including the inclusion of the relay agent
interface address in the REPLY message, allowing hard-coded server
addresses as well as the all-servers-multicast address in relay
agents, and addition of an explanation of known security
vulnerabilities to the security issues section of the drafts were
discussed.
Finally, the WG conducted a lengthy discussion about the interaction
between addrconf and DHCP mechanisms. The issue arises from the
effect of the router advertisement 'M' bit on addresses obtained
through DHCP and the effect of prefixes marked as deprecated in router
advertisements on addresses obtained through DHCP. The interaction is
further complicated by the potential exploitation of the router
advertisement as a denial-of-service attack through the insertion of
bogus router advertisement messages, which would cause hosts to
discard valid addresses. The interaction between DHCP and the
Neighbor Discovery protocol will be defined by the addrconf working
group and documented in the next revision of the Neighbor Discovery
protocol specification. The text about the interaction in the DHCPv6
protocol specification will be replaced with a reference to the
Neighbor Discovery protocol specification.
