2.3.2 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98


Ralph Droms <droms@bucknell.edu>

Internet Area Director(s):

Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.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:

This working group will produce a protocol for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. Specific functions to be included in the protocol include:

o Automated allocation and recovery of IP addresses

o Automated configuration of all TCP/IP stack parameters, as described in the Host Requirements documents

o Interaction between DHCP and DNS dynamic update protocol (ddns)

o Automated configuration of other host parameters such as application layer services

o Inter-server communication for coordination of multiple servers

o Mechanisms for the authentication of clients and servers

A specification the Dynamic Host Configuration Protocol (DHCP) for IPv4 has been entered into the IETF standards track. As of 3/97, it has been accepted as a "Draft Standard". The working group is also developing a specification for DHCP for IPv6 (DHCPv6), which is currently available as an Internet Draft.

Goals and Milestones:



Revise the DHCPv6 Internet-Draft for discussion at the Dallas IETF meeting.



Submit the DHCP options specification to the IESG for consideration as a Draft Standard.



Submit server-server protocol specification as an Internet-Draft.



Submit FQDN, option 127 and option acceptence process documents to IESG for consideration as a Proposed Standard.



Develop options for automated registration in DNS.



Submit the DHCPv6 Protocol and options specification for WG Last Call.

Nov 97


Complete revisions to the DHCPv6 protocol specifications based on response to the IETF Last Call.

Dec 97


Submit the DHCPv6 protocol specifications to the IESG for consideration as a Proposed Standard.

Sep 98


Submit the DHCP Protocol specification to the IESG for consideration as an Internet 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

Current Meeting Report

The DHC WG met twice in Orlando. Thanks to Barr Hibbs for taking notes for these minutes. The first meeting was a one hour meeting in which the failover protocol was discussed. The second meeting was used for discussion of general DHCP issues.

The failover meeting included a ten minute overview of the protocol, ten minutes of collecting questions and the remainder of the meeting addressed the collected questions. Kim Kinnear (cisco) presented an overview of the current protocol draft spec, the protocol status and recent developments. The draft is progressing and identified problems are being hammered out. There are two implementations (which are not yet interoperable). The draft authors feel that there is not widespread understanding of the current draft. Bernie Volz (Process Software) gave a brief review of the RUTS BOF meeting (which is addressing the issue of developing a new transaction-oriented internet protocol).

After the overview, a list of questions were collected. The list has been posted to the dhcp-serve@bucknell.edu mailing list. The remainder of the meeting was used to generate answers to questions 1-4 and 7. The other questions will be discussed on the dhcp-serve list.

The second WG meeting included discussion of various DHCP issues. Bernie Volz began with a summary of the LDAP schema developers' meeting held in November. The attendees developed objectives and initial schema model, common objects and a containment hierarchy. The group considered coordination with the Desktop Management Task Force (DMTF). The next step will be to write a draft describing the proposed schema.

Several old drafts were resurrected. Mark Stapp (cisco) reviewed the status of the "DHCP-DNS Interaction" draft, which he will revise to address the open issue of name disambiguation. The draft will then go back to the WG for standards track review. Pratik Gupta (IBM) revived the "Domain Search" option. Two issues arose: how to encode multiple domains in a single option and should the option go into the current option space or the new ("futures panel") option space. The WG consensus was to specify multiple options through length-encoded encapsulation and to include the option in the current option space. The specifics of the encapsulation mechanism will be coordinated with the data representation standards being developed by the futures panel. Ralph Droms (Bucknell) reviewed the "User Class" option. Two issues will be moved to the mailing list: syntax and semantics for encoding multiple classes in the option and how can a DHCP server tell the client what classes are available to choose from. A follow up draft, specifying rules for address assignment using the "User Class" option, was discussed. The WG consensus was to review this draft for acceptance as an informational RFC. Erik Guttman (Sun) discussed the most recent revision of the "SLP Server" option draft. One issue about a flag byte to override local configuration with the configuration in the DHCP message was raised and will be discussed further on the mailing list. Burcak Beser (3COM) discussed the use of the vendor class identifier by VoIP equipment. WG input was that the vendor class identifier may be appropriate to identify the vendor of the equipment. Erik Guttman suggested SLP may be a better mechanism for providing more individualized configurations through a bootfile.

Ralph Droms and Bill Arbaugh (Univ. of Pennsylvania) reviewed revisions to the authentication protocol draft. Peter Ford (Microsoft) expressed concern that the current draft over-specifies the protocol by prescribing some details of the implementation. The WG discussed the issue of privacy in the client identifying itself to a server before learning the identity of the server; after a short discussion, the current protocol was found to allow "server-first" identification if the client leaves any identification out of the DISCOVER and the servers are configured to respond to anonymous DISCOVER messages with an OFFER that includes some identification of the server. Finally, there was a request for an example specification of a version of the authentication protocol using PK technology.

Mike Carney (Sun) gave a brief review of the activities of the futures panel and the current draft. Updates to the draft will be posted soon for final discussion at the next WG meeting. Kim Kinnear gave a brief summary of the failover protocol meeting. Finally, Ryan Troll (CMU) summarized the current state of the IPv4 autoconfiguration drafts and asked for WG input as to handling of the drafts - BCP vs. STD? The conversation will continue on the mailing list.


Delimiter Vs Encapsulation
DHC SLP Options
LDAP Schema for DHCP