CURRENT MEETING REPORT

Reoprted by Ralph Droms, Bucknell University

Minutes of the Dynamic Host Configuration Working Group (dhc)

Thanks to Lowell Gilbert and Shawn Mamros for taking notes during the DHC sessions.

The first DHC Working Group session focused on DHCPv4. See the accompanying slides for an outline of the agenda and discussion topics.

Ralph Droms led short discussions on a series of small DHCPv4 Internet Drafts:

1. New option approval process:

Each new option will be documented in a separate RFC and submitted to the standards process separately. There was no objection to this proposal from the working group. The new option approval process will be added to the options specification.

2. Reserve option 127 for expansion:

Option 127 will be reserved as a prefix for two-octet options subcodes, (greatly) expanding the option number space. Each instance of option 127 will include only one subcode option. Based on a suggestion from the working group, option 126 will be reserved as an extended parameter request option (like option 55). The Internet-Draft will be extended to include the definition for option 126 and will then be resubmitted.

3. FQDN option code:

This new option specifies that the parameters defined within the option are specified as FQDNs rather than 32-bit internet addresses. The working group considered and rejected a suggestion to use RFC 1035 encoding rather than a plain character string.

4. DHCP renumbering:

This proposal will be published as soon as the chair reformats the text from Lowell Gilbert.

The working group listened to a proposal from Rob Stevens and Ralph Droms describing a server-server protocol for DHCPv4. The basis for the protocol is to allow servers to allocate, extend, and release bindings asynchronously. Servers will coordinate only when required to avoid re-allocation of an address that is already in use.

The server-server protocol provides a mechanism for ongoing, background database reconciliation as an optimization so that new and extended leases can be propagated to multiple servers. Servers are required to reconcile their databases at the time an address is marked for allocation, to ensure that an allocated address has not already been assigned to a host by some other server.

There are a few constraints and concerns. The protocol assumes fairly closely synchronized clocks on the servers which may require NTP. Netadmins may need to be careful about the timing of updates among servers so that server-server traffic doesn't become excessive. Rob and Ralph will write up their proposal in more detail and publish it as an Internet-Draft.

Yakov Rekhter described his Internet-Draft on DHCP-DNS interaction. His Internet-Draft presumes that a DHCP client and server will want to, at the minimum, update an A record and a PTR record. In all cases, the server will update the PTR record. The client and server must negotiate which will update the A record (may depend on local policy and DNS authority). Other issues:

• When should a server do an update - between receipt of DHCPREQUEST and transmission of DHCPACK.
• Should DHCPACK include error indications - probably yes.
• How should DNS records and DHCP lease be synchronized - should DNS include an expiration time for records, or should DHCP clients and servers be responsible for removing DNS records when DHCP leases expire?
  

Paul Vixie announced a freely available DHCP implementation. Look for more information in http://www.fugue.com/dhcp. The new release is at ftp://ftp.fugue.com/pub/DHCPD-BETA-1.tar.gz and diffs between Beta 0 and Beta 1 are in the same directory in DHCPD-BETA-0-1.diff.gz.

Ralph Droms and Laird McCulloch presented proposed schemes for DHCP client and server authentication and message verification. Droms presented a scheme developed by Jeff Schiller and Christian Huitema that uses a single, shared private key. McCulloch presented a scheme based on public key technology. Both proposals will be published as Internet-Drafts and further discussion will happen on the working group mailing list

The second meeting focused on DHCPv6.

There was one small piece of DHCPv4 business. Krishnan Parameshwaran asked about using DHCP to configure an entire subnet rather than individual hosts. The motivation here is for sharing of limited address space among many dial-up sites, each of which has an entire subnet rather than just a single DHCP host. It was pointed out that a router requires many more configuration parameters than a host, and that DHCP may not include options for all of those parameters. Further discussion will take place on the working group mailing list.

Jim Bound and Charlie Perkins presented their DHCPv6 specification, as published in their latest Internet-Draft. See the slides from their presentation for additional details. DHCPv6 will support multiple addresses per host interface. These addresses can be requested through multiple client-server transactions. Each address is represented as an extension, so that a DHCPv6 message may carry 0, 1 or more than 1 address. Each address extension also carries other information, such as the client identifier and the FQDN associated with the address.

Clients solicit link-local agents and servers for the addresses of DHCP servers. The client then selects a server and unicasts to the server (possibly through an agent) for configuration parameters.

A client can request that it's entire current state be deleted from the server when it obtains a new address, for state synchronization between clients and servers.

DHCPv6 includes an explicit RECONFIGURE message which can be sent from servers to clients to force clients to confirm their current configurations.

Some questions raised during the presentation:

• Suppose a client doesn't maintain state between reboots. The client may choose a different server, in which case the old server will have an old, unused lease. The old lease will eventually expire. Perhaps some more proactive mechanism might be developed as an optimization.
• In a related scenario, if a client moves between two nets managed by the same server, the server will not recognize that the old address is no longer in use.
• The relay agent is part of the binding, but suppose the agent is renumbered? A client should use DHCPv6 whenever the client has an indication that its address is out of date. For example, the client can detect that it has moved to a new subnet through neighbor Discovery. In that event, the client should use DHCPv6 to obtain a new address.
• Will the RECONFIGURE message scale to 10^5 clients? Should netadmins depend on RECONFIGURE as reliable (i.e., reliable delivery and reliable reconfiguration by client) or should RECONFIGURE be considered "advisory"?