DHC WG Meeting minutes
IETF 55, Atlanta, 11/2002
=========================

Administrivia, agenda bashing, Ralph Droms

------------------------------------------
CableLabs Client Configuration option draft is in IETF last call.  So far, 
the last call has elicited comments requiring some editorial and minor 
specification changes.

DHCPv6 specification has been reviewed by IESG, and requires small edits to 
text describing relay agent security.  Droms will post summary of 
changes to WG mailing list.


Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay Agents and 
Servers, Ralph Droms

----------------------------------------
-------------------------

draft-droms-dhcp-relay-agent-ipsec-00.txt describes use of IPsec for 
securing messages between relay agents and servers.  Carl Smith asked if it 
is different than the mechanism in the DHCPv6 draft; answer: no.  Narten 
asked for comparison with Stapp's 
draft-ietf-dhc-auth-suboption-01.txt.   Droms noted IPsec mechanism is 
hop-by-hop while authentication options covers entire path; IPsec 
mechanism incurs extra complexity if there are multiple relay agents in the 
path to the server.  The WG agreed to take the document on as a WG 
document.


The Authentication Suboption for the DHCP Relay Agent Option, Mark Stapp

----------------------------------------
--------------------------
draft-ietf-dhc-auth-suboption-01.txt specifies a DHCP-specific 
mechanism, based on a relay agent suboption that contains a message 
digest for checking message integrity.  This mechanism uses shared keys and 
includes an identifier mechanism to accommodate edge devices that don't use 
giaddr.  With additional changes, this mechanism can accommodate 
multiple, nested relay agents.

The WG was asked what to do with the two proposals: advance both, adopt 
one?  Does the WG have a clear understanding of the two proposals?  Ted 
Lemon asked how we might weight the pros and cons.  Thomas Narten and 
Stuart Cheshie asked if there is any data on whether IPsec 
implementations are available to relay agents today.  Mark Stapp asked 
about potential computational complexity issues.  Stapp, Lemon and John 
Schnizlein all asked what the perceived customer requirements are.  Droms 
expressed concern about interoperability if both proposals are 
advanced.  Erik Nordmark asked how relay agents would be configured to use 
IPsec or with the keys for the relay agent option.  Droms pointed out that 
reuse of IPsec technology implies the availability of future IPsec 
enhancements.  Schnizlein volunteered to organize discussion of pros and 
cons of both proposals on the WG mailing list.


DHCP Option for SNMP Notifications, Mark Bakke

----------------------------------------------
draft-bakke-dhc-snmp-trap-01.txt was developed to address 
requirements for systems using diskless boot to obtain a list of IP 
addresses to which to send SNMP traps.  Narten asked which WG is best for 
discussion of this option - in theory, details should be discussed in an 
SNMP WG with final review of syntax and compatibility in the dhc WG.  
Narten will coordinate review of the document with MIB groups in the IETF, 
and the document will ultimately be a dhc WG work item, as there are no 
appropriate active SNMP WGs.  There was a question about whether the 
option should be expanded with multiple sub-options for different trap 
types.


Subnet Allocation using DHCP, Richard Johnson

---------------------------------------------
This proposal describes a mechanism through which a DHCP server can 
delegate a block of addresses (IPv4), collect usage data on the 
delegated addresses and deprecate use of addresses.  It is similar to the 
prefix delegation mechanism for DHCPv6.  Ted Lemon pointed out that this 
proposal would require a major revision to existing server, and he 
suggested that the authors review previous, related work by Walt Lazear.  
The WG agreed to take on this document as a WG work item.


DHCP Server-ID Override Suboption, Richard Johnson

--------------------------------------------------
Some DHCP client messages, such as DHCPRENEW, are unicast directly to the 
DHCP server and not received by a relay agent.  Thus, relay agents are 
unable to add relay agent options to those messages.  This proposal 
provides a mechanism through which the DHCP server can configure the 
client to respond to the relay agent rather than directly to the server.  
Narten asked if continued expansion of relay agent options is a good 
thing.  WG consensus is that relay agent options have been found to 
provide function that cannot be provided in other ways, and the full range of 
application for relay agent options is still being explored.  Stapp 
suggested revisiting the relay agent option specification, RFC3046, as a WG 
charter item.  The WG agreed to take on this document as a WG work item.


Considerations for the use of the Host Name option, Carl Smith

----------------------------------------
----------------------
Carl had one question for the WG: how can a client request that its 
name/address association be removed from DNS?  Can we use the FQDN to 
accomplish this result?  Kim Kinnear and Ted Lemon asked what customer 
requires this result.  Bernie Volz suggested revisiting this question 
after the DHCPv6 FQDN model is completed.


Load Balancing for DHCPv6, Bernie Volz
--------------------------------------
Any more changes needed in this draft?  No; so this document is ready for WG 
last call after DHCPv6 spec has advanced.


Other DHCPv6 options, Ralph Droms
---------------------------------

draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt has folded prefix 
delegation into identity associations; the document is also under 
discussion in the ipv6 WG.


draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt, 
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt, 
draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt are all ready for WG last call as 
soon as DHCPv6 advances.

draft-ietf-dhc-dhcpv6-opt-dstm-01.txt and 
draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt are to be synced up with v6ops 
work.

Lemon, Volz and Narten all asked about the requirement for the 
mechanism proposed in 
draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt.  A K Vijayabhaskar 
(author) to clarify motivation and requirements in the 
specification.


A Guide to Implementing Stateless DHCPv6 Service, Ralph Droms

----------------------------------------
---------------------
Droms asked the WG about the best way to specify the parts of DHCPv6 
required for stateless DHCPv6 operation ("DHCPv6-lite") - for example, for 
providing DNS server configuration without address assignment.  Stuart 
Cheshire asked if the document should be informational or 
standards-track.  Another possibility would be BCP.  The WG asked that the 
Reconfigure message be added to 
draft-droms-dhcpv6-stateless-guide-01.txt and accepted the document as a dhc 
WG work item.


Revised DHC WG charter and milestones, Ralph Droms

--------------------------------------------------
Droms reported that the revised charter and milestones have been 
submitted to the IESG.  The IESG suggested adding a separate charter item to 
develop a mechanism through which a client can authenticate a server 
without authentication of the client by the server.  Droms will add the 
relay agent charter item suggested by Stapp (see above).

Carl Smith, Bernie Volz and Barr Hibbs volunteered to be a design team that 
will follow up on the charter item to review RFC3118; they will develop a 
threat model and analysis of the authentication provided by RFC3118.  Barr 
Hibbs volunteered to coordinate and act as editor for a review of the 
DHCPv4 specification.


Recycling option codes, Ralph Droms
-----------------------------------
There are more than 15 options codes that have been assigned but never 
used.  Droms will publish an Internet Draft identifying these option codes 
and asking for feedback from the Internet community about whether these 
option codes can be returned to IANA for reassignment.  After the 
Internet Draft has been reviewed by the dhc WG and by the IESG, it will be 
submitted to IANA.


DHCP Lease Query, Kim Kinnear
-----------------------------
The WG last call on 
draft-ietf-dhc-leasequery-05.txt has completed.  Based on input from the 
last call, Kinnear has changed the draft to use a new option rather than 
overloading the requested address option, and has made other editorial 
changes.  The document is now ready for submission to the IESG.


Link Selection sub-option for the Relay Agent Information Option, Kim 
Kinnear

----------------------------------------
-------------------------
Last call on 
draft-ietf-dhc-agent-subnet-selection-04.txt has completed.  This 
document is waiting for authentication of relay agent messages to be 
resolved.


DHCP Subscriber ID Suboption for the DHCP Relay Agent Option, Richard 
Johnson

----------------------------------------
---------------------
This option, in 
draft-johnson-dhc-subscriber-id-00.txt, is motivated by a 
requirement to identify a subscriber in a relay agent option, 
regardless of the port to which the subscriber is attached.  The WG 
agreed to take on this document as a WG work item.


DHCP Option for Geographic Location, John Schnizlein

----------------------------------------------------
This option, in 
draft-polk-dhcp-geo-loc-option-00.txt, passes location information about a 
DHCP client from the server to the client.  The immediate purpose is to 
provide location information to IP phones.  The geopriv WG will own the 
semantics, while the dhc WG will own the protocol and the syntax of the 
option.


The DHCP Client FQDN Option, Mark Stapp
DDNS-DHCP conflict resolution, Mark Stapp

-----------------------------------------

Stapp reported on 
draft-ietf-dhc-fqdn-option-05.txt, 
draft-ietf-dhc-ddns-resolution-05.txt, 
draft-ietf-dnsext-dhcid-rr-05.txt.  There are no deployed 
implementations of these drafts.  Cisco and two others have 
(non-interoperable) implementation that use TXT RRs, waiting for 
approval of DHCID RR.  Droms asked for a summary of changes to the 
current drafts.  Stapp will post summaries to WG mailing list.  
Gudmundsson asked if the DHSID RR should become a more general RR type.  WG 
consensus was no, as that would delay progress of these drafts and there is 
no specific requirement for other, similar RR types.  Gudmundsson and 
Droms agreed documents are ready for dnsext and dhc WG last call.