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.