DHCP WG meeting notes from Montreal

[Ralph Droms <[e-mail]>]

DHCPv4

Ralph Droms gave a status report on the DHCPv4 documents.  The four core
documents - DHCP specification, DHCP options, BOOTP clarification and
DHCP-BOOTP interaction - are on track for promotion to Draft Standard.  The
FQDN option and extension option documents are on track for acceptance as
Proposed Standard.  The graceful renumbering (from Lowell Gilbert) and
DHCP-DNS interaction (from Yakov Rekhter) documents are in revision.  The
authentication and server-to-server protocol documents are in development.

The WG agreed on several small changes to the DHCP documents prior to
publication as Draft Standards:

* Clarify text so "user class" interpretation is not a MUST requirement for
  servers
* Change text so lease time MUST NOT/SHOULD NOT requirements in DHCPINFORM
  are consistent
* Change text in section 4.4.2 so that the known IP address MUST be
  inserted (to match table)

Several other protocol details and extensions were discussed:

* Should DHCPDECLINE be unicast (NO! WG has concluded [several times!} that
  DHCPDECLINE must be broadcast (DECLINE implies client has no IP address)
* In response to an inquiry about ISP/session-oriented parameters, there
  will be a discussion on the mailing list to begin development of options
  for such parameters
* After a discussion of an mechanism to indicate the "preference" of
  configuation parameters - e.g., existing vs. new lease, primary vs.
  backup server, static vs. dynamic allocation - the WG concluded that
  such a mechanism could be developed as an option.  This option will be
  proposed in a separate I-D through the new option acceptance procedure.
* Jim Bound discussed hs proposed solutions to the problem of configuring
  remote subnets through, e.g., on-demand, dial-up router service.  A
  document will be developed that will either be added to the DHCP FAQ
  or published as a DHCP-related RFC.
* Discussion of a DHCP MIB will be started on the DHCP mailing list.

The server-to-server and authentication protocols were discussed.  An ad
hoc group met briefly right after the WG meeting to review the presentation
about the server-to-server protocol given at the WG meeting in Los Angeles.
Ted Lemon volunteered to begin an I-D defining the server-to-server
protocol.  Ralph Droms will expand the authentication I-D into an option
specification; this specification will allow for other authentication
mechanisms in addition to the private key mechanism described in the
authentication I-D.

DHCPv6

Jim Bound and Charlie Perkins have issued new versions of the DHCPv6
protocol spec and extensions I-Ds.  The specification I-D includes bug and
architecture fixes, authentication extensions, movement of the "L" bit,
multicast RECONFIGURE message handling, multicast address for server
addresses and a comparison between DHCPv6 and DHCPv4.  The extensions I-D
includes bug fixes, inclusion of each address/name as a separate extension,
specification of the multicast RECONFIGURE extension, an extension for
renumbering servers and a description of the authentication extension.

The WG discussed a couple of proposed features:

* Unsolicited advertisements by servers/relay agents - rejected as
  unneeded.
* Hints to client about preference levels (as in DHCPv4) - seems to be
  needed
* Relay agents check off-link servers periodically - needed to prevent
  forwarding stale information about servers to clients

There was a discussion of the DHCPv6 relay agent architecture in which
relay agents cache server information rather than passing solicit requests
through to servers.  As there is no implementation experience on which to
make a decision (based on traffic, difficulty of implementation, etc.), the
WG agreed to accept the mechanism as described in the current I-D; however,
this architecture may be reconsidered in the future.

Authentication is seen as crucial, especially in preventing attacks through
the RECONFIGURE message.   The DHCPv6 authentication mechanism is based on
IPv6 mecahnisms and will prevent authentication, verification and replay
protection.

Future plans for DHCPv6:

* Begin implementation - including DNSIND, IPSEC and the authentication
  extension)
* Inlcude DHCP in the UNH bakeoff in November, 1996
* Revise the specification and submit for Proposed Standard after San Jose
  IETF meeting (December, 1996)

Once again, thanks to Shawn Mamros for taking the notes on which these
minutes are based.