Editor's note: These minutes have ont been edited. 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.