DHC WG minutes

["Ralph E. Droms" <[e-mail]>]

Attached are the minutes from the DHC WG meeting in LA.  Please reveiw
and respond to me with corrections and additions.

As these minutes are already late, I need to ask for your input by
Thursday, 3/28.

- Ralph

=====

Thanks to Lowell Gilbert and Shawn Mamros for taking notes at the DHC
WG meetings.

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

Tuesday AM (DHCPv4) session minutes:

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 from the WG to this proposal.  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 WG, option 126 will be
reserved as an extended parameter request option (like option 55).
The I-D will be extended to include the definition for option 126 and
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 WG 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 WG 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 I-D.

Yakov Rekhter described his I-D on DHCP-DNS interaction.  His I-D
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 server do 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
I-Ds and further discussion will happen on the WG mailing list

Tuesday PM (DHCPv6) session minutes:

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 WG mailing list.

Jim Bound and Charlie Perkins presented their DHCPv6 specification, as
published in their latest I-D.  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 its 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 - 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"?