Subject: Minutes from DHCPv4 discussion at WG meeting

From: Ralph Droms <[email-masked]>
Date: Thu, 09 Aug 2001 10:07:05 +0100

Thanks to Stuart Cheshire for taking the notes on which this summary
is based.  Please respond with comments, additions, corrections by 8/13 so 
I can submit and publish the minutes.  The final minutes will include both 
these notes from DHCPv4 and the notes from the DHCPv6 discussion I 
previously posted to the DHCPv6 mailing list.

- Ralph

Ralph gave a summary of WG status and activities:

The DHCP Reconfigure Extension has been reviewed by IESG; it was
subsequently revised and resubmitted by the authors.  The draft is now
waiting IESG re-review.

Ralph asked if there are any existing or planned implementations of DHCP
Authnetication. None are existing. One person said they had a planned
implementation.

Several drafts are ready for WG Last Call:
* Encoding Long DHCP Options
* The Classless Static Route Option for DHCP
* DHCP Domain Search Option
* The DHCP Client FQDN Option
* Resolution of DNS Name Conflicts Among DHCP Clients
* Subnet Selection sub-option for the Relay Agent Information Option
* Addition of Device Class to Agent Options

Ralph will initiate WG last call for these drafts after IETF-51.

Ralph asked for someone to volunteer to write a document listing all
known DHCP vendor options. Barr Hibbs volunteered.

Failover Protocol, Mark Stapp
<draft-ietf-dhc-failover-09.txt>
------------------------------------

Mark asked whether draft is ready for last-call. The hum from WG
indicated the WG thinks it is.  Ralph will initiate a WG last call
after IETF-51.

802.1X WEP Key Management using DHCP, Bill Arbaugh
<draft-ietf-dhc-key-management-00.txt>
--------------------------------------------------
Bill's draft proposed doing key management via a DHCP option. Every
time client renews its lease it gets a new WEP key. This could allow
the WEP key to be changed fairly frequently - e.g. every five minutes.

Stuart Cheshire asked if this functions duplicates 802.1X
functionality? Answer: Yes, but 802.1X is not widespread yet, and we
want this now. However, it's not clear how long this will take to get
deployed. For example, the Mac OS 9 DHCP client would need to be
updated to request this new option, and no new updates are planned for
OS 9 now that all Apple's efforts are focussed on OS X. In contrast,
an 802.1X client can be implemented by any third-party without any
special support from the OS, so it is likely that 802.1X could be
implemented far quicker than this DHCP extension.

Mark Stapp thought the draft was worth pursuing.

Erik Nordmark expressed concern that pursuing this option confuses
users by providing two ways to do key management, and ultimately slows
adoption of either. It is better to focus efforts on deploying 802.1X.

Show of hands for who would like work to continue on this draft: Only
Ralph raised his hand.

DHCP mDNS Enable Option, Erik Guttman
<draft-guttman-dhc-mdns-enable-01.txt>
--------------------------------------
Erik presented a summary of client mDNS default behavior and the
function of a proposed option to enable the use of mDNS.

Stuart Cheshire pointed out that the proposed default behaviour, if
the DHCP server does not support this option, is that Multicast DNS
should not be used. This basically means that today, Multicast DNS
will not be allowed to work on any network where DHCP servers are
present, which in turn means that there is no incentive for anyone to
implement Multicast DNS.

Resolution?

LDAP Schema for DHCP, Vijay Nanjundaswamy
<draft-ietf-dhc-ldap-schema-00.txt>
-----------------------------------

Vijay K. N. spoke about the latest LDAP schema definition.  Mark Stapp
noted that including lease information has huge performance
implications.  Ted Lemon gave the opinion that if the schema can be
defined to accommodate the DHCP server data and work at some scale,
then the schema is valid and the performance problem should be tackled
separately.

The schema recommends isolating leases in a container object to
improve manageability.  There is a server-specific extension that
holds information that is only relevant to one particular
implementation server.  Mark Stapp asked if the authors had surveyed
DHCP implementations to see if there is enough common configuration or
operational information to make an interesting schema.  Erik Guttman
notes that the DMTF stays away details like this schema for individual
services.  Vijay identified an action item to survey existing servers
to determine common functions.

Ted Lemon pointed out that claiming improved reliability through the
use of and LDAP store just moves the single point of failure from the
DHCP server to the LDAP server.

Mark Stapp asked if there is enough commonality between the
configuration options and features of different DHCP Servers for a
common LDAP schema to be useful?  Authors responded that they will do
a summary of existing servers to determine applicability of a common
LDPA schema.

Erik Guttman asked who actually wants this?

Ted Lemon suggested that the authors should try implementing it first
before talking about publishing it as an RFC.

The authors have received comments from the WG and modified the draft
according to those comments (where appropriate).  The authors have
also made some other changes independent of WG feedback.

VPN Identifier sub-option for the Relay Agent Information Option,
DHCP VPN Information option	Mark Stapp
-----------------------------------------------------------------

These drafts carry similar information through a DHCP option and a
relay agent sub-option.  The drafts give two encodings for VPN
identifier: vrfs and RFC2685 vpn id.  No response from WG.