2.3.2 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 06-Jul-99


Ralph Droms <droms@bucknell.edu>

Internet Area Director(s):

Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>

Internet Area Advisor:

Thomas Narten <narten@raleigh.ibm.com>

Mailing Lists:

General Discussion:dhcp-v4@bucknell.edu
To Subscribe: listserv@bucknell.edu
In Body: subscribe dhcp-v4 Your Name
Archive: Send email to listserv@bucknell.edu with HELP as the text.

Description of Working Group:

Other Lists:

DHCP-DNS interaction: dhcp-dns@bucknell.edu DHCP implementions: dhcp-impl@bucknell.edu DHCP bake-offs: dhcp-bake@bucknell.edu Failover protocol: dhcp-serve@bucknell.edu DHCPv6: dhcp-v6@bucknell.edu DHCPv6 implementations: dhcp-v6impl@bucknell.edu

This working group has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard" (RFC2131, RFC2132). The working group now has four main objectives:

* Revise and submit the DHCP specification for acceptance as a Full Standard

* Develop a roadmap for the review and acceptance of new options, define a new option syntax, develop an accurate list of assigned option codes and identify option codes that can be safely reassigned

* Develop a specification for DHCP for IPv6

* Develop an inter-server communication for coordination of multiple servers

* Review new options for DHCP, as deemed appropriate by the working group chair and/or the Internet area directors; specific options currently under review in the working group include:

o Mechanisms for the authentication of clients and servers

o Interaction between DHCP and DNS dynamic update protocol

o Definition of a DHCP MIB for management of DHCP servers through SNMP

o Definition of an LDAP schema to provide a standardized format for the storage and retrieval of DHCP information, primarily configuration and lease data; this schema will be developed in coordination with the Policy Frameworks Working Group as appropriate.

o Options through which DHCP relay agents can pass information to DHCP servers

o Other options: user class, server selection, domain search

Goals and Milestones:

Jun 99


Submit Internet-Draft on subnet selection option in time for Oslo IETF

Jun 99


Submit Internet-Draft on DAP schema for DHCP in time for Oslo IETF

Jun 99


Submit Internet-Draft on DHCP authentication in time for Oslo IETF

Jun 99


Submit Internet-Draft on failover protocol in time for Oslo IETF

Jun 99


Submit Internet-Draft on relay agent options in time for Oslo IETF

Jun 99


Submit Internet-Draft on DHCP-DNS interaction in time for Oslo IETF

Jul 99


Submit Internet-Draft on DHCP authentication for WG last call

Jul 99


Develop plan for review of DHCP specification and acceptance as Internet Standard.

Sep 99


Submit DHCP server MIB specification for WG last call

Sep 99


Submit subnet selection option specification for WG Last Call

Nov 99


Submit DHCP server MIB specification for IESG consideration as a Proposed Standard

Nov 99


Submit LDAP schema specification for WG last call

Mar 00


Submit LDAP schema specification to IESG for consideration as a Proposed Standard.


Request For Comments:







Interoperation Between DHCP and BOOTP



Clarifications and Extensions for the Bootstrap Protocol



DHCP Options and BOOTP Vendor Extensions



Dynamic Host Configuration Protocol



DHCP Options for Novell Directory Services



Netware/IP Domain Name and Information



DHCP Option for The Open Group's User Authentication Protocol



Procedure for Defining New DHCP Options



DHCP Options for Service Location Protocol

Current Meeting Report

The DHC working group met twice in Oslo. The first meeting was used for discussion of DHCPv4 issues. Thanks to Stuart Cheshire for taking notes for these minutes. Here is a summary of discussion
items and resolutions:

- Support for PK authentication
- Replay counter field replaced with replay-detection field
- MAC field replaced with authenticator field which may contain PK signatures as well as shared-key MAC
- In response to question about merging Droms/Arbaugh and Gupta protocols, WG consensus is to leave as two separate protocols. Droms/Arbaugh will review Gupta proposal to determine if modifications to packet format are warranted to accommodate Gupta "replay detection method" field.

- WG agreed to collapse all DHCP mailing lists into two lists: dhcp-v4 and dhcp-v6
- No support for user class option; will confirm with message to mailing list and then remove from WG charter
- Bill Sommerfield agreed take over server selection option
- Mark Stapp agreed to complete option code recovery process

The second WG meeting was used for discussion of recent developments in DHCPv6 process:

- Develop list of issues to resolve; obtain WG consensus that list is as complete and appropriate as possible
- Develop solutions to issues from list; obtain WG consensus that solutions are correct
- Revise document based on solutions
- Obtain WG consensus that solutions are captured in revisions to specification
- Revise document for WG last call
- WG last call

- List of issues: 8/15/99
- Solutions to issues: 10/ 1/99
- Revised draft: 11/10/99 (Washington IETF)
- Consensus on solutions
- Revised draft: 3/ 1/00 (Australia IETF)
- WG last call

- Current technical issues

- DHCPv4 features to carry forward/misfeatures to avoid/missing features to add

- DHCPv4 current work to review

- DHCPv6 new features

- List of client-supported options
- Client can explicitly reject options as unsupported/unrequested
- Alternative actions: what to do if option unrecognized, unrequested, ...
- Requested values: client gives range of desired values

- What is a "resource"?
- What is "releasable"?

- Document structure


None received.