DHC WG Minutes - DHCPv4 The DHCPv4 meeting was attended by approximately 45 persons. Thanks to Glenn Waters for taking notes. These minutes were prepared by the WG chair, Ralph Droms. The chair opened the meeting with discussion of some administrative matters. Because of increased emphasis on security issues within the IETF standards process, future standards from the DHC WG must include a "Security Considerations" section. The document should reference the "Security Considerations" section in the latest DHCP specification RFC (currently RFC2131), as well as describing any additional security exposures and/or solutions specific to the particular document. The WG expressed consensus for issuing a WG last call for the following Internet Drafts, prior to submitting these drafts to the IESG for acceptance as Proposed Standards: An Extension to the DHCP Option Codes (draft-ietf-dhc-options-opt127-03.txt) An option for FQDNs in DHCP options (draft-ietf-dhc-fqdn-opt-03.txt) DHCP Options for Novell Directory Services (draft-provan-dhcp-options-dir-serv-01.txt) Netware/IP Domain Name and Information (draft-ietf-dhc-netware-options-00.txt) Mike Carney raised the issue of adding a new option to track the version of the DHCP, so that clients and servers can indicate which features they support (and don't support). An alternative mechanism using a bit-mask to indicate supported features was suggested. There was a comment about the need for versioning relay agents, too. Mike volunteered to summarize the issue and kick off a discussion on the dhcp-v4 mailing list. Baiju Patel gave a presentation about multicast address allocation, as described in draft-ietf-dhc-mdhcp-01.txt and draft-ietf-dhc-multopt-01.txt. This proposal describes extensions to DHCP that will support distribution of multicast addresses from servers to clients. The proposal is based on the reuse of DHCP for address requests and distribution, while some other mechanism employed by the MDHCP servers coordinates the selection and announcement of newly allocated multicast addresses. There is some buy-in from other IETF WGs to use MDHCP for handling multicast addresses. Some issues were raised in the ensuing discussion: * "About 75%" of DHCP is not needed for MDHCP; is there enough commonality to warrant reuse? * The DHCP model of "one address per interface" will no longer work. * Leases on multicast addresses must be transferable, as the host to which the lease was originally issued may leave the multicast group before the end of the lease on the multicast address. * What options should be used in the DISCOVER phase? How will the client describe its request to the server? * What port number should be used - e.g., how will using the BOOTP/DHCP port number affect interoperability? * Authentication? Baiju will summarize the issues and continue the discussion on the dhcp-v4 mailing list. Mark Stapp gave a presentation about the inter-server protocol, as described in draft-ietf-dhc-interserver-02.txt. Requirements for the inter-server protocol include: * Must work with existing clients * Must ensure cooperating servers don't offer same address to two different clients The design goals for the inter-server protocol include: * DHCP servers are administered as "groups" * DHCP server groups can auto-configure themselves through the inter-server protocol * Once a client has been given an address, it can perform subsequent DHCP functions 9e.g., lease extension) through any server in the group * "Lazy update" is supported, so that updates to all servers in the group need not be completed before a server responds to a client * Servers can continue to function in the event of partial network failure (e.g., network partition) Mark posed some questions to the WG: * Does the WG want a protocol that meets these goals? * Does the protocol, as described in draft-ietf-dhc-interserver-02.txt, work? * Is layering on SCSP appropriate?questions about SCSP running on UDP and * Are there alternatives; e.g., SNMP? Following up on the question about layering on SCSP, there were concerns raised about SCSP running on UDP and about the lack of any existing SCSP implementations. The chair suggested that the questions raised in the discussion need to be broken out for further discussion on the dhcp-serve mailing list. The WG next undertook a discussion about authentication and security in DHCP. Olafur Gudmundsson began with a review of the issues. As a bit of history, Olafur recalled the original proposal by Schiller, Huitema and Droms (draft-ietf-dhc-authentication-04.txt) and the analysis that this proposal was unacceptable because the mechanism would not scale well. He went on to review briefly WG discussion about subsequent proposals. Several additional requirements - over and above those currently listed in draft-ietf-dhc-security-arch-01.txt - were endorsed by the WG: * authentication/authorization should be a REQUIRED component of DHCP; should include: - client authentication - data integrity - server/relay agent authentication * mechanism must scale to multiple servers and administrative domains * mechanism must incur low administrative costs Continuing the discussion of authentication for DHCP, Baiju Patel described his proposal for secure DHCP using temporary addresses. The key idea is to use an unsecured temporary network address to bootstrap a security association and an authenticated DHCP message exchange, in a three-step process: * bring up minimal networking without authentication - a "temporary" address * establish a security association * extend the lease on the temporary address or request a new address One issue raised by the WG is that this mechanism does not prevent a denial of service attack through the exhaustion of temporary addresses. Olafur Gudmundsson next gave a presentation about his latest security architecture. In this architecture, both client and server provide enough information initially for full authentication. It requires a public key distribution mechanism; currently, the proposal specifies DNSSEC. In response to a question from Olafur, the WG expressed consensus that the DHCP security mechanism need not be applicable to DHCP for IPv6. Olafur and Baiju agreed to collaborate on a mutual review of their two proposals; the review will be forwarded to the WG to guide further evaluation of the security proposals. Ralph Droms gave a short description of changes included in Michael Patrick's revised "Agent Options" Internet Draft (draft-ietf-dhc-agent-options-02.txt): * security requirements section added * several options consolidated into one option In the ensuing discussion, three issues were raised: * are these options really required? * is there overlap with related work? * are these options too specific to Motorola? The WG expressed consensus that the "Agent Options" Internet Draft needs further discussion and revision before consideration as a Proposed Standard. Next, Yakov Rekhter gave a presentation about the latest revision to the DNS/DHCP interaction Internet Draft (draft-ietf-dhc-dhcp-dns-04.txt). This latest revision includes a change in the way PTR RRs are handled: the previous draft specified that the PTR RR would first be deleted and then added to the RRset; the new revision specifies that the PTR RR is simply added to the RRset. The WG discussed the problem of multiple clients using the same FQDN - how can clients and servers use DNS correctly to detect and avoid using an FQDN already in use by another client; while allowing clients to change FQDNs (and PTR RRs) when appropriate. Mark Stapp proposed two solutions, based on using either the TXT RR or a new (TBD) RR. Mark will write up and publish the two solutions for review by the WG, and discussion will continue on the dhcp-dns mailing list. Mark Townsley concluded the meeting with a presentation about the subnet selection option (draft-ietf-dhc-subsel-00.txt). The idea is for the client to give the server additional information about which subnet the client would like an address from. The WG asked about sites in which the server should retain control of address allocation; Mark responded that, in such cases, the server would ignore the option and allocate an address according to server policy. There was also a question about the need for this option given that 'giaddr' and server configuration (with topology information about multiple IP subnets on a wire) can perform a similar function. The WG agreed to continue discussion of the issues on the WG mailing list. DHC WG Minutes - DHCPv6 The DHCPv6 meeting was attended by approximately 50 people. Thanks to Dan Harrington for taking notes. These minutes were prepared by the WG chair, Ralph Droms. The chair opened the meeting with a review of the "last call" process for the DHCPv6 Internet Drafts. Because of the limited response to the WG last call, in which the chair explicitly asked for positive responses from anyone who had read the documents, the chair, with the consent of Jim Bound and Charlie Perkins (authors of the DHCPv6 Internet Drafts) requested external reviews of the documents. Matt Crawford and Erik Nordmark graciously agreed to review and report on the documents; many thanks to Matt and Erik for the time and energy they invested in their careful reviews and thorough reports. Both reports raised issues that need to be resolved prior to submitting the DHCPv6 specifications for Proposed Standard status. Prior to the WG meeting in Munich, the external review reports had been posted to the dhcp-v6@bucknell.edu mailing list and the authors had responded to the points raised in the reviews. The latest revisions of the DHCPv6 specifications (draft-ietf-dhc-dhcpv6-10.txt and draft-ietf-dhc-v6exts-07.txt; about 75% of those present at the meeting reported having read these or the immediately previous drafts) include changes by the authors in response to most of the issues raised in the external review reports. Jim Bound started off the WG discussion of the current drafts with a short list of issues that can be resolved quickly: * consistency of wording/terms/phrases * bindings require relay agent prefix, not host link-local address * "silently discard" should be replaced by "system error" (as per RFC 2119) There was some discussion about the relay agent prefix issue, as there may be multiple relay agents on a link; those agents might use addresses with different prefixes, which the servers would have to sort out to establish equivalences among binding identifiers. Jim listed issues that require WG discussion for technical resolution: * Multicast REQUEST/SOLICIT messages (scalability) * Reconfigure processing * Transaction ID on reboot and sequence number wrap-around protection * ICMP messages through relay agents, especially for PMTU discovery * DDNS updates * DDNS error code processing * API for IPv6 - excess baggage in packets Jim led off with a discussion of dynDNS-DHCP interaction issues. WG had feedback with editorial changes - some SHOULDs need to be MUSTs. Jim and Charlie will make modifications in their next draft. Next, Jim discussed RFC 2136 error codes and DHCPv6. At present, the dynDNS error codes are mapped into DHCPv6 extension error codes. This mapping may, in some circumstances, mask some information from the client and adds complexity to the server and to the protocol spec (which must track any changes to the dynDNS error codes) itself. On the other hand, some dynDNS error messages may not make sense to the client. Jim and Charlie will review the current mechanism before issuing the next revision of the Internet Drafts. The next issue arises from a client that reboots and loses its last transaction ID. The server will have a cache of recent transactions from that client; that transaction cache must be able to differentiate between a restarted client and transaction ID wrap-around. WG consensus was to reserve small integer transaction IDs (e.g., 0-31) for rebooting clients and skip those transaction IDs in the event of wraparound. Jim raised the issue of "excess baggage" in the DHCPv6 messages - some information, e.g., IPv6 source address, is duplicated in the IPv6 header and the DHCPv6 messages. Jim suggested that the IPv6 API makes access to the IPv6 header information simple, and the redundant fields should be elided from DHCP messages. Jim and Charlie will revise the packet formats to eliminate redundant information and add words to the drafts describing exactly where to find all the necessary information (either IPv6 header or DHCPv6 message) for DHCPv6 processing. The results will be included in the next revision for WG consideration. The multicast issue was raised by Erik Nordmark in his review of the DHCPv6 specifications. In an environment with multiple relay agents on a link and multiple DHCP servers in an organization, use of multicast forwarding by relay agents would cause one copy of each client SOLICIT message to be delivered to each server from each relay agent. In turn, the client might receive multiple responses from each server (potentially number_of_relay_agents * number_of_servers messages). Such behavior would not scale well in an environment with many relay agents on each link and many DHCP servers. In the ensuing discussion, Ralph Droms suggested that an election process among relay agents, in which the collection of relay agents on a link would elect a single relay agent to forward client messages, would reduce the number of messages delivered to DHCP servers. Erik suggested in his review an expanding ring mechanism through which the multicast scope would initially be limited and subsequently expanded as necessary to locate a DHCP server. There was some disagreement about whether an expanding ring search will find the appropriate server; the *closest* server might not necessarily be the *best* server. The WG generally agreed that clients should be simple and that relay agents and servers should be administered to limit the transmission of DHCP messages; however, experience with DHCPv4 indicates that there is room for complexity on the client side - some clients may need to participate in the decision about which server to choose. The WG strongly recommended that the DHCPv4 "server selection" option, in which server choices are prioritized by a simple mechanism (currently, an integer indicating the "preference" or "priority" for a server; client simply chooses highest preference server) be used as a model for client-side selection. The discussion concluded with the recommendation that the multicast mechanism be retained, with additional mechanisms so that relay agents can reduce the number of forwarded messages (presumably, reduce to one) and servers can minimize and prioritize their responses. The authors were asked to consider an applicability statement to provide guidance to DHCP system administrators in configuring DHCP clients and servers to minimize DHCP network traffic. The last major issue was processing of reconfigure messages. the first question was in the description of the semantics of the reconfigure message - in particular, is the server responsible for ensuring that all clients have responded to the reconfigure message? Does the server need to continue attempting to contact clients until any outstanding leases have expired? Discussion of this question will continue on the WG mailing list. Another issued is the interaction between DHCP reconfigure and stateless autoconfiguration - can action from DHCP invalidate an address obtained through stateless autoconfiguration and vice versa? Some additional issues: * The extensions draft is missing the vendor class identifier - Jim and Charlie will add the appropriate definition. * Are FQDNs appropriate for client identification of an IP address? Is there a latency issue in dynDNS updates? * Should a server issue an explicit response if it has no available addresses? Consensus was that current behavior - no response - is appropriate. * A representative from the Year2000 WG asked that the DHC WG review the DHCPv6 specification for date issues.