Editor's Note: These minutes have not been edited. The DHC WG met for four one-hour sessions. One session was used for each of old business, DHCPv6, new business and ongoing discussion. Note that all internet draft names in these minutes are published with the "draft-ietf" prefix and ".txt" suffix elided. Old business: ============= Glenn Stump discussed three related options: user class (dhc-userclass-01), server selection (dhc-sso-00) and server identification (dhc-sio-00) options. The WG agreed that the user class option could be considered for Proposed Standard. Glenn agreed to write a BCP document to accompany the server selection and server identification options prior to review for submission as Proposed Standards. Ralph Droms asked for comments on the most recent version of the DHCP-DNS interaction document (dhc-dhcp-dns-03). There were concerns raised about the requirement that a DHCP server wait until the DNS update completes before responding to the DHCP client; this delay may cause significant performance problems. The WG asked for the following revisions: * Allow the DHCP server to respond to the client without waiting for the update * Additional response code to indicate DHCP server timed out waiting for the DNS update to complete * Additional words about administrative control; e.g., DHCP server may want to do all updates within its domain, but allow the DHCP client to do updates on names outside the server's domain. Michael Patrick spoke about the agent options (dhc-agent-options-00): * circuit ID (identifies the circuit to which the DHCP client is attached; used for reverse routing back to the client) * remote ID (additional identifier for the remote agent) * subnet mask (used to pass the subnet mask for the client from the remote agent to the DHCP server) The WG raised authentication as an issue; any options added by the remote agent would not be included in a message digest computation from the DHCP client. There are also some details to be worked out about whether a client can insert agent options and whether the remote agent should strip any agent options out of DHCP messages returned to the DHCP client. Charlie Perkins discussed the Service Location Protocol option. The WG asked that the option be extended to carry FQDNs as well as IP addresses; otherwise, the option is ready for Proposed Status. Ralph Droms (for Don Provan) asked if there was any final discussion about the NDS options (draft-provan-dhcp-options-dir-serv-00.txt). Absent any discussion, the option was recommended for Proposed Standard status. Mike Carney described changes in the POSIX timezone option (dhc-timezone), made in response to comments from discussion at a previous WG meeting. The WG approved submission of the POSIX timezone option for Proposed Standard status. DHCPv6: ======= The DHCPv6 spec and extensions docs (dhc-dhcpv6, dhc-v6exts) had been posted to the WG mailing list for WG last call prior to the WG meeting. A minor problem with the pad extension was discussed. The WG also suggested that there were editorial corrections that must be made prior to submission to IETF last call. Jeff Schiller raised a question about security and key management - in an environment with potentially many keys, how does the DHCP client know which key to use? The authors will revise the spec and extensions docs to address this issue. New business: ============= Pratik Gupta proposed a domain search option. The WG pointed out potential confusion between option 15 (domain name) and the domain search option and suggested that text be included to avoid any potential confusion. The WG requested a draft be written for the proposed domain search option. Pratik Gupta then opened what turned out to be a wide-ranging discussion no the development of a DHCP MIB. Issues in the discussion included: * previous work (CMU, et al.) * scope of the MIB - monitor only - monitor and some control - complete configurability * notifications - low water mark on free addresses per subnet - unauthorized address use detected - failed to give out address because pool exhausted - failed to give out address because of authorization failure - failed DNS update * should MIB include per-client binding for all clients (yes) * should relay agents have section in MIB or a separate MIB? Stuart Kwan discussed a proposal for an option to supply a URL for a proxy configuration file (kwan-proxy-client-conf-00.txt). There was no WG consensus to either move forward or reject. Several objections were raised: * vendor-specificity, * requires new mode of DHCP operation to return application-specific information * should this be a SVRLOC function? * Clarification for mixed-media subnets Ralph Droms (for Sam Martel and Walt Wimer) discussed a clarification for the use of DHCP and BOOTP over mixed-media subnets (martel-bootp-mixedlinklayers-00.txt). The draft had not been widely read; WG consensus was to publish as separate clarification or to integrate the material into the next revision of the DHCP spec. Takeshi Nikida initiated a preliminary discussion on dynamic subnet allocation (dhc-dyn-subnet-conf). The WG expressed interest and suggested continued development. Munil Shah discussed options and modifications to DHCP for support of multicast addresses (dhc-mdhcp, dhc-multopt). Although there was some sentiment within the WG that this is an orthogonal problem and a separate protocol might be more appropriate, the WG consensus was to suggest continued development. Kester Fong initiated a preliminary discussion on dial-up clients and DHCP. The primary issue is handing out multiple addresses to a dial-up subnet. Possible solutions include a DHCP proxy, agent options, or implementing a DHCP server in the dial-up server. Ongoing discussion: =================== Mike Carney gave a quick review of the results of DHCP testing at the latest Connectathon. He reported that there were no major issues in the protocol specification, and that vendors are glad to see that the DHCP spec and options have been issued as Draft Standard RFCs. Outstanding issues in DHCP identified at Connectathon include multiple subnets on a wire, authentication and a protocol validation suite. Bob Cole (dhc-interserver) and Kim Kinnear (dhc-interserver-alt) led a discussion on their two (somewhat complementary) drafts. There was much discussion about what the inter-server protocol should do and how it should do it. Bob and Kim will get together and try to merge ideas into unified draft. Olafur Gudmundsson (dhc-security-arch-00.txt) led a spirited discussion on DHCP security. The new security architecture ID was discussed, which addresses fundamental problems with earlier authentication draft (dhc-authentication-03.txt). Concern was expressed that the new architecture would be too expensive computationally to scale well. The WG consensus was to continue the discussion on the mailing list. ______________ Editor's Note: These minutes were submitted separately. draft-ietf-dhc-interserver-alt-00.txt The "ALT" draft Kim Kinnear American Internet Corp. kinnear@american.com Key Features/Issues: 1. Use of "lazy" update removes requirement for inter-server messages between DHCPREQUEST/SELECTING and DHCPACK. 2. Servers will continue to service client requests even in the event of network partition. If a client can talk to *any* DHCP server -- even if "its" DHCP server is gone -- it can continue to use its address and will experience *no* interruption of service. 3. Administrator can add/remove server from the group at will. Identification and removal of failed server is responsibility of administrator. ------------------------------------------------------------- Failure Scenario _________ | bridge | ----------------------------------------------------- | | | | | | | | | | | | +------+ | | +------+ |server| | | |server| | A | | | | B | +------+ | | +------+ | | | | +------+ | +------+ |client| | |client| | X | | | Y | +------+ | +------+ | partition boundary Suppose that client Y receives a lease from server A. Then the bridge fails, partitioning the network. Due to the "lazy" update the DHCPACK made it to client Y prior to the partition of the network, but the "PUSH" operation from server A to server B did not complete. Client Y will attempt to renew several times, and fail since it can't talk to server A. Eventually, client Y will broadcast a rebinding which server B will receive. Since server B knows nothing about client Y, it will ask the other servers in the group (in this case server A) about client Y. When it fails to get an answer, server B will renew client Y's lease on its IP address. This works because an IP address cannot change the client to which it is bound without the entire server group's awareness. (It *can* become bound for the first time to a client without full knowledge -- it just cannot *change* to be bound to a different client without full knowledge by all servers). During the partition event, client X can still DISCOVER and receive an address from server A. ----------------------------------------------------------------- Why have configuration messages? Don't we want the administrator to configure the group? YES! ... and in order to provide a long-term reliable DHCP service, we need to give the adminstrator the tools necessary to administer the group. Functions required: 1. Add a server to a group (or single group-capable server) "already in progress". 2. Remove a server from a group (either operational or failed). 3. Servers verify basic configuration information. (Should we verify not just subnets, but actual addresses in subnets?) ----------------------------------------------------------------------- Could SCSP be used to support the general "semantics" of the ALT draft? Well ... let's try to map ALT operations into SCSP operations. ALT Operations SCSP Operations -------------- --------------- Address Information Messages: POLL & COMPLETE POLL Client State Update Solicit (CSUS) PUSH Client State Update (CSU) DUMP CSUS TRANSFER ? Configuration Messages: Determine the available groups ? GROUP JOIN ? GROUP LEAVE ? ANSWER: It is certainly worth a try!