CURRENT MEETING REPORT Minutes of Dynamic Host Configuration Working Group (DHC) Reported by Ralph Droms, Bucknell University The Monday meeting concentrated on a discussion of issues raised during the review of the latest DHCPv6 draft. These issues were listed and discussed in turn: o When should DHCPv6 be used? The issue was raised about when DHCPv6 should be used under all circumstances when the network prefix might have changed (as in DHCPv4) or only when the client is sure the network prefix has changed (using IPv6 router advertisements, etc.). The Working Group arrived at a consensus that *some* words about this situation are needed in the specification. Whether those words specify that DHCPv6 should be used only when the client knows the prefix has changed (implementor's choice whether to use DHCPv6 at other times), or that DHCPv6 should be used when there is some chance the network prefix might have changed (as in DHCPv4) will be discussed on the mailing list. DHCPINFORM for DHCPv6 The Working Group reached consensus that DHCPINFORM (ask for network parameters without involving any network addresses) should be included in DHCPv6. o Selecting client addresses-client classing mechanisms The Working Group reached consensus that, based on experience with DHCPv4, a classing mechanism should be added to DHCPv6. o Carrying more than one address per DHCP message This is still an open issue. To avoid delaying progress on development of DHCPv6 spec, the Working Group reached consensus that the DHCPv6 message header should carry one address and that additional messages (if allowed) will be carried in options. o Lease extension More words may be needed to clarify how a client requests an extension on an existing lease. o Retransmissions The Working Group reached consensus on a small change in client behavior. Client will retransmit ACCEPT if the client does not receive a SERVER-ACK. If the client still does not receive a SERVER-ACK after several retransmissions, the client will restart the DHCP process and send a DISCOVER message. In this model, the client drives all retransmissions (both DISCOVER and ACCEPT). o Hardware type for interface ids DHCPv4 uses ARP types to differentiate hardware types in interface identifiers. This mechanism has several problems; e.g., there are some types of interfaces (PPP, ISDN) that do not have ARP types. The issue needs further discussion on the mailing list. o Client release-early lease revocation This is a sticky problem, with no good solution in sight. The discussion included some observations: if early revocation can be made absolutely reliable, leases are unnecessary; the problem can occur with any lease (not just infinite leases) that needs to be revoked before its expiration, requiring clients to use DHCPv6 whenever their parameters might have changed (reboot, reconnected to network) would provide at least a partial solution. This issue will be discussed further on the mailing list. o What ports should be used by relay agents The current DHCPv6 document specifies that relay agents should forward DHCP messages to the UDP DHCP client port (rather than the server port), so that servers can differentiate between messages received directly from clients and messages forwarded by relay agents. The consensus of the Working Group was that the potential gain did not outweigh the potential impact of broadcasting to the client port, which would be received by all DHCP clients on the subnet. The document will be revised to specify that relay agents will forward DHCP messages to the UDP DHCP server port. o Duplicate address flag The Working Group reached consensus that the client should always do duplicate address detection and that the flag was not needed. The DHCPv6 document will revised to remove the flag. o Dynamic updates to DNS The Working Group reached consensus that DHCPv6 should (probably) adopt whatever strategy is adopted by DHCPv4. o Relay agent and authentication IPv6 provides for security in the IP layer. Unfortunately, DHCP relay agents change the contents of the DHCP message, thus the Ipv6 end-to-end security mechanism won't work. One possible solution is to use authenticate the client-relay agent link and the relay agent-server links separately. Further discussion of the issue will take place on the mailing list. o Transaction ID Clients use the same transaction ID in all retransmissions of a DHCP message, so the message types that indicate retransmission are unnecessary, and will be removed from the specification. Tuesday's meeting focused on DHCPv4. Several members of the Working Group made short presentations about specific outstanding issues. Yakov Rekhter described a model for the coordination of dynamic updates to DNS records through DHCP. The basic model assigns each record an "owner," and the owner is then responsible for performing any DNS updates. Clients and servers use DNS to negotiate ownership of the DNS records. By default, the client assumes ownership of its A record, and the server assumes ownership of the associated PTR record. In some situations, at the discretion of the local network administrator, the server may retain ownership of the A record. In any case, the owner of the DNS record uses the dynamic DNS update protocol to make any necessary changes. The lifetime of these DNS records should be coordinated with any network address lease times assigned through DHCP, so DNS does not carry along stale information. As the Working Group expressed no serious objections, Yakov agreed to write up his proposal as an I-D for review by the Working Group. The proposal will be implemented entirely as DHCP options and will be compatible with the existing protocol specification; thus, there is no need to delay progression of the current protocol specification through the standards process. Ralph Droms gave a brief status report. The latest draft of the DHCP specification has been submitted for draft standard; the latest options document will be submitted soon. He asked about whether RFCs 1542 and 1534 should also be submitted for draft standard (they are both currently proposed standards and are unchanged since publication); the consensus of the Working Group was to also move those documents through the standards track. Ralph also raised the issue of new options: how should new options be reviewed and accepted as part of the DHCP specification. The current procedure is to contact IANA for a new option number, which is then incorporated into a re-published version of the options document. There is currently no formal review of new options. Alternatives such as review by the DHC Working Group, or process modeled on those used by other Working Groups (MIME or TELNET) will be discussed in the Working Group mailing list. Finally, the Working Group was asked to review Charlie Perkins' proposal for support for mobile IP through DHCP options. Charlie's I- D will be reviewed and either incorporated into the existing options document or published as a separate RFC. In the middle of the status report, the Working Group took a moment to discuss the issue of passing FQDNs in options instead of 32-bit IP addresses. Ralph and Yakov engineered a solution they had apparently come to in parallel: a "FQDN encapsulation" option will be defined. This new option will indicate that the encapsulated option (one of the other DHCP options) contains a FQDN rather than a 32-bit IP address. A few details need to be worked out-how does a client indicate it can parse the FQDN encapsulation option and what syntax will be used to pass a list of FQDNs. Yakov and Ralph will write up a specification as an I-D for the Working GroupÕs review. Lowell Gilbert described a plan for "graceful renumbering" that he and Yakov have developed. A written description of the plan is available from ftp://ftp.epilogue.com/pub/lowell. This plan, similar to the graceful renumbering procedure defined for DHCPv6, describes how a DHCPv4 client can obtain multiple addresses that can be used for a graceful transition. Lowell and Yakov have carefully constructed this plan so that it can be implemented entirely in DHCP options and it requires no changes to the base DHCP protocol; thus, the progression of the protocol need not be delayed while this plan is developed. The issue of transitioning from DHCPv4 to DHCPv6 was raised: should a client in transition run DHCPv4 to obtain its DHCPv4 addresses and DHCPv6 to obtain its DHCPv6 addresses? The question was sufficiently ugly to warrant discussion on the Working Group mailing list. Following up on a discussion in the Working Group meeting in Danvers, the Working Group discussed security and authentication issues. The consensus in the Working Group was that, while authenticated DHCP cannot guarantee secure operation of a network, it could contribute by only allocation IP addresses to valid clients. Further, the ability to authenticate servers would reduce problems caused by incorrectly configured or malicious servers. Laird McCulloch cited evidence that a variety of users are interested in "secure DHCP" and will not consider using DHCP until some form of authentication is included. The Working Group listed some different methods that might be employed: RSA, IPSEC, whatever is chosen by DNSIND, CHAP, etc. There was a strong consensus that the Working Group choose one authentication mechanism and avoid interoperability problems that might result from any negotiation of alternatives between clients and servers. Finally, there was a question about using DHCP to allocate subnets instead of just addresses. For example, a dial-up router might need a subnet address for a remote subnet. This issue will be brought to the Working Group mailing list.