2.2.2 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00


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:

A separate mailing list is used for discussing the IPv6 version of dhcp: dhcp-v6@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

Meeting Manager: Ralph Droms (WG Chair)

Minutes prepared by: Richard Jones

Monday, Jul 31 at 1930-2200 (DHCPv4)

Ralph officially announced that he has taken a position with Cisco Systems in the Boston area. He has taken a one year leave of absence from Bucknell University, but expects it to extend beyond that time frame. He stated that acting as DHCP Working Group Chair is now officially a part of his job, so expects to devote more time to it.


RFC 2855 (DHCP for IEEE 1394) is accepted by the IESG as a Proposed Standard.

Drafts draft-ietf-dhc-nsso-05.txt and draft-ietf-dhc-authentication-14.txt have been submitted to the IESG for considerations as Proposed Standards.

draft-ietf-dhc-new-opt-msg-02.txt is accepted by the IESG as a Best Current Practice (BCP) document.

The following drafts have been returned, with comments, by the IESG for further revision:

draft-ietf-dhc-pv4-reconfigure-01.txt will be revised based on feedback from WG Last Call before being submitted to the IESG.

The DHCPv6 specification and the server-to-server drafts are currently under construction.


Draft: DHCP-DNS Interaction
Presenter: Mark Stapp

The original draft has been broken out into two drafts, based on feedback from the Adelaide IETF meeting: the 'fqdn draft', draft-ietf-dhc-fqdn-option-00.txt, and the 'resolution' draft, draft-ietf-dhc-ddns-resolution-00.txt. The resolution draft references a dnsext draft, draft-ietf-dnsext-dhcid-rr-00.txt, which refreshes an expired draft.

It is expected that these drafts will undergo one or more revisions before being ready for WG Last Call.

It was suggested that a bit flag be added to the fqdn option format that allows a client to request that the server do no DNS updating at all for this request. Current option flags only specify that the client can request the server not update the A RR. The consensus was that this is fine, but that the server reserve the right to override the client request.

It was suggested that the DHCID Resource Record be encoded in Base 64 rather than hexadecimal format. This was agreed upon, with Andreas Gustoffson volunteering to provide existing 'boilerplate' documentation for this provision.

The question of having the server update other RR's than the A and PTR records was raised again. Also, the possible need for multiple PTR records was raised. It was agreed that these need to be discussed on the mailing list in greater detail.

The question of whether or not a client can send multiple fqdn options in a request was raised. The prevailing opinion seemed to be opposed to this, especially since the current convention for multiple options in a DHCP packet only deals with options having lengths greater than the maximum option size, meaning that the values of all the multiple options are concatenated (which would not be the case here). This question will also be referred back to the list.

Mark placed the following issues before the group:

1. Was the draft division the right thing to do?
2. Are there use cases (or scenarios) that need to be added to the resolution draft?
3. Who has implementation experiences they can share that will contribute to refining the draft?


AUTHOR: Add the flag bit to the fqdn option as requested. Change the encoding scheme for the DHCID RR as requested. Initiate mailing list discussions of the questions brought up in the meeting, and the ones the author brought to the meeting.

Draft: DHCP Authentication using Kerberos
Presentor: Poornima Lalwaney

Poornima gave a detailed presentation of the draft. There is an existing Kerberos DHCP draft (draft-hornstein-dhc-kerbauth-02.txt). Poornima contrasted the two drafts, stating that the Hornstein draft posits a tight coupling between the DHCP server and the Kerberos state machine(s). The Medvinksy draft de-couples the server to a large degree by placing initial key management responsibilities on an 'iakerb proxy', which is specified in a current kerberos draft (draft-ietf-cat-iakerb-03.txt).

The Medvinsky draft proposes using the client's hardware address in AS_REQ and TGS_REQ host address fields by using a negative value in the 'host address type' field, as specified by the IAKERB draft. The 'source IP address' field would be left at 0.

It was noted that in order for the Medvinsky draft to succeed, the iakerb proxy draft must be modified. The proxy draft implies (but doesn't state explicitly) that the GSS API must be used to access proxy mechanisms. The Medvinsky draft would extend the proxy draft to allow 'raw' kerberos messages to be handled by the proxy as well.

Ted Lemon advocated adoption of the Hornstein draft, because he feels that requiring modification of server behavior is preferable to requiring modification of client and/or relay behavior. It was noted that the authors of the Hornstein draft are not moving it forward; Ted offered to assume that responsibility.

It was noted that there is not currently working group consensus on which draft to move forward.

ACTION ITEMS - DHCP Authentication using Kerberos

AUTHORS: The authors (or representatives) of both Kerberos drafts will prepare motivation/discussion documents that will be presented to the mailing list for discussion, with the goal of determining which draft should be moved forward. The documents will be available to the list by October 1, 2000, with this discussion to be resumed at the next IETF Meeting.

Presentor: Ralph Droms

The five main charter points were agreed upon by the group with the following changes/additions:

1. The issue of DHCP authentication is to be moved from a sub-category to a full charter requirement.

2. The LDAP and DHCP MIB projects will be added as full charter requirements.

3. The interaction between the DHCP WG and the IPV6 autoconf WG, while a major issue, is covered in the DHCPv6 charter point.

The milestones list is outdated. Ralph will get date information from several people on the status of their respective drafts.

Specific milestone issues include:

a list of open issues concerning the review of the DHCP protocol for Standard is needed. This might be accomplished by publishing the list as an intermediate or informational I-D.

The Classless Static Routes and NameServer Search drafts will shortly be ready for Working Group Last Call.

The New Options Guidelines draft has been split into two drafts, and the goal is to have them ready for WG Last Call in the near future (i.e., before the next IETF meeting).

ACTION ITEMS - Charter and Milestones

AUTHOR: Ralph will modify the Charter and submit it to the list for comment. He will solicit date information from draft authors who are represented in the milestones list, update the milestones list and submit it to the list for comment.

Presentor: Bernie Volz

A new version of this draft, based on detailed feedback from a couple of sources, will be issued in late August.


AUTHOR: will issue -03 version of the draft.

DRAFT: Load Balancing
Presentor: Bernie Volz

The -02 version of this draft has been published. It consists mostly of wording changes and cleanup. Bernie asks that this draft be sent to WG Last Call.

DRAFT: Failover
Presentor: Bernie Volz

The -07 version of this draft has been published. It consists mostly of editorial changes, with minor technical changes. The draft's author was unable to attend, so discussion of the draft was postponed to the list, and likely to a conference call meeting to be held in the fall.

Bernie stated that more discussion (and draft language) is needed to deal with the issue of reserved address handling, based on Cisco's current implementation experiences. The open issues, which are listed in the draft, are generally straightforward, and should be dealt with in the interim meeting.

Area Director Thomas Narten stated that the IESG requires substantial advance notice for interim Working Group meetings, and a consideration of time constraints and convenience on a global level, to make working group meetings internationally inclusive. He clarified that this was not a criticism of the DHC group's handling of meetings, but rather a reiteration of requirements for how they should be announced and conducted. In general, meeting announcements should be made around a month in advance when possible, and in any case more than a week in advance. They should also try to take into account the problems of time zone differences between interested parties, in the case of conference calls.


AUTHOR: The draft's main author, Kim Kinnear, will post a meeting notice to the mailing list no later than early October. The format of the meeting will most likely be a conference call.

Presentor: Richard Barr Hibbs

Barr stated that a new revision of this draft will be submitted in mid to late August. There have been delays due to disagreements over MIB content and implementation issues which are still in the process of resolution. The draft should be ready for WG Last Call after one more round of feedback on the upcoming revision, followed by a succeeding revision.

It was asked whether or not the server MIB draft was considered a gating item for the DHCP protocol to go to Standard. Thomas stated that the IESG does not consider it so.


AUTHORS: prepare the next revision for submission before the end of August.

Presentor: Subir Das

Subir gave a detailed presentation on the Dynamic Registration and Configuration Protocol (DRCP). The primary objectives are improvement over DHCP in the areas of real-time speed, a reduction of bandwidth, and a minimization of broadcast usage. These objectives are primarily intended to benefit wireless- and mobility- oriented customers.

The main differences of DRCP are: significantly reduced packet size, the possibility for a two-message rather than four-message exchange, and a difference in header format between client-to-server and server-to-client messages.

The draft is still in its early stages. Subir stated that the authors are still working to refine their objectives and debating basic issues.

The group responded by asking how many of these ideas could be considered for incorporation into the existing DHCP protocol. It was also pointed out that many of the ideas presented in this draft have interesting possibilities with regard to the DHCPv6 drafts.


AUTHORS: The draft authors will work with Ralph to prepare a list of DRCP features that might be candidates for integration with the existing protocol. This will be submitted to the mailing list (time frame was not specified) for discussion.


Tuesday, Aug 1 at 0900-1130 (DHCPv6)

Meeting Manager: Ralph Droms (WG Chair)
Presenter: Mike Carney, with Charlie Perkins and Jim Bound

The agenda was:

1. Determine the DHCPv6 I-D drafts' readership

2. Discuss open issues with the drafts

3. Determine the next step for the drafts

Mike established that fewer than ten per cent of the meeting attendees have read the latest DHCPv6 drafts, which were published in May of this year (draft-ietf-dhc-dhcpv6-15.txt, and draft-ietf-dhc-dhchpv6exts-12.txt).


Issue 1: Releasable resources

Mike referred to a discussion section in the draft that treats the use of 'releasable resources' in a generic manner. In fact, the only releasable resource currently defined is IP address. There was a concern that the draft's treatment of the subject may be confusing, so Mike asked the group if the text should be changed. There was no comment, so the text remains as is.

Issue 2: Client requests for multiple addresses, and any-time requests for addresses/parameters

The draft protocol allows for, but does not require, that clients be capable of requesting multiple addresses in a transaction, and that they be able to contact a server and request addresses and/or parameters at any time. There was agreement that this adds complexity to the draft (see Complexity issue below). There was not consensus on whether or not this constitutes a gating issue, or how (or if) it should be approached.

Issue 3: Client requests to multiple servers

The draft protocol allow for, but does not require, that clients be able to make requests for addresses and parameters to different servers. When asked, Mike asserted that the capability was optional. Jim asserted that the draft is sufficiently clear on this. Mike suggested that the draft be reorganized to have clear sections for a 'core', or minimal, application of the protocol, followed by clearly-delineated sections describing more sophisticated possibilities. One meeting participant agreed strongly. There were no dissenting opinions.

Issue 4: Dynamic client reconfiguration

Mike asked the group if this issue has been adequately treated in the draft. He mentioned the two sections discussing passive and active renumbering scenarios, including the ability to limit the number of reconfigured clients by using recyclable multicast addresses. One comment was that the number of clients to be reconfigured may not be known beforehand, making the use of multicast difficult. The matter was left for further consideration.

Issue 5: Clients, Duplicate Address Detection and address release

The draft calls for clients who deduce address conflicts using a DAD mechanism to send a release message to the server, using a 'bad address' status. Mike asked the group if this would be adequate. There was no comment, so it was assumed to be okay.

Issue 6: Enumeration of legal extensions for each message type

Mike asked the group if the draft should explicitly list all valid extensions for each message type. It was pointed out that this approach doesn't scale well when new extensions are adopted. The suggestion was made and approved that the draft follow the technique of the DHCPv4 failover draft, which lists the 'options' that are mandatory for each message type, the 'options' that must NOT be supplied, and leaves all others as 'optional'.

Issue 7: Multi-link subnets are explicitly not supported

Mike asked the group for consensus on the explicit non-support in the draft for multi-link subnets. It was suggested that since the real issue here is that client DAD does not work in this case, that specific language be added to the draft to explain the non-support's motivation. Suggestion was approved.

Issue 8: Do extensions need to be padded or aligned?

Mike asserted that extensions are explicitly not to be padded, since the length field of an extension makes their size clear. String instances of extensions are not to be null terminated, and byte- or bit-alignment is not a requirement. It was suggested and approved that specific language to this effect be added to the extensions draft.

Issue 9: Relay agents are not allowed to modify the contents of a message in flight.

Mike asked the group if this was too restrictive. The consensus was that it is too restrictive, especially in the light of the DHCPv4 relay agent option (currently draft status) that explicitly has a relay agent adding to the 'options' field of a message. However, it was strongly suggested that language be added to the draft stating that having a relay agent modify a message has major implications for end-to-end authentication and integrity checking.

Issue 10: More detailed description of client behavior when a transaction fails

The draft currently provides little direction for clients when they receive a non-zero status after a transaction. Charlie stated that there is no protocol mechanism for this instance, and asked the group for guidance. There were suggestions made for and against having the client 'call somebody', with no clear agreement. There was agreement, though, that there should be a detailed mapping between error status values and some form of human-interpretable message, to make troubleshooting a reasonable proposition.

Issue 11: Which method of DHCP authentication should be used?

The current DHCPv6 draft has provisions for authentication methods. Mike asked the group to decide if these should stay, or if another method should be referenced. The consensus appeared to be that the draft's authentication mechanism should be removed and the current V4 DHCP authentication draft should be referenced. This draft is due to be considered for Proposed Standard by the IESG in the near future, and was considered a good bet. Ralph cautioned that things such as a relay agent modifying a message must be dealt with explicitly in the v6 draft. It was also suggested that a section be added to the extensions draft covering the translation from DHCPv4 option format to v6 extension format for the proposed authentication option.

Issue 12: Implementation state diagrams

Mike stated that there had been a request for state diagrams, but they have not been drawn up yet. The suggestion was made that the term 'implementation' is misleading, and should be changed. The term 'protocol state diagram' was suggested. There appeared to be consensus on that name.

Issue 13: The extension carrying the DHCPv6 protocol version is missing

Issue 14: Almost no feedback on the draft. Why?

This issue was discussed in several ways throughout the meeting. There are several important sub-issues, which appeared to break down into two main themes: protocol complexity, and working group process.

Protocol complexity

There were several complaints concerning the complexity of the draft, and the difficulty of reviewing it. While it was pointed out that there are many more complicated drafts and standards, it was acknowledged that this draft could stand to be organized more clearly along the lines of what is 'core' protocol and what is 'allowable to a sophisticated client'. There did not appear to be consensus on whether or how this should be done, largely due to perceived serious time constraints on getting the draft to Proposed Standard.

There were also many perceived 'barriers to implementation'. One problem cited was that of determining the 'core protocol'. Another was the perception of unnecessary complexity, e.g. the different header sizes for each message, and the potential presence or absence of header fields based on bit flags in the same header.

The draft also leads people to infer that there is an API implied that interfaces applications and a DHCPv6 client. The authors agreed with this, but did not agree on how or whether the 'implicit' API should be treated in the draft. Two current implementations of the protocol were cited; one that exercises the 'full' protocol, and one that is partial. It was strongly pointed out that many more implementations are needed asap to gain more knowledge of the protocol's strengths and weaknesses. It was also pointed out that interoperability is crucial to the success or failure of the protocol.

Working group process

Observations were made that some non-author working group members feel that historically the DHCPv6 process has been non-inclusive, and that feedback, when given, has not been acknowledged or acted upon. The authors agreed to seriously consider this issue, and look quickly for solutions.

Ralph suggested that perhaps the group should go back to an analysis of the differences between DHCPv4 and v6 in an effort to solidify and simplify the v6 draft. This was favored by some and viewed as a likely distraction by others, so consensus was not reached.

It was pointed out that IPV6 development is accelerating rapidly. The time frame of six months was given as a practical limit for getting a Proposed Standard for DHCPv6 with much hope of having it be widely implemented. While the exact time frame was not agreed upon, there seemed to be consensus that there is not sufficient time for another major draft revision.

It was suggested that an interim meeting between seriously concerned group members be scheduled approximately three weeks from this meeting date (around Aug. 21, 2000). Meeting participants are expected to have thoroughly studied the drafts, and to have well organized lists of expectations for how to proceed from here, so the next steps can be negotiated.



1) no action to be taken.

2) no consensus. This remains a major open issue.

3) no action to be taken.

4) further consideration is needed to decide if the current draft's treatment of the issue is adequate.

5) no action to be taken (draft language to be left as is).

6) revise the extensions draft to use the enumeration technique suggested.

7) add language to the protocol draft to express the reason for explicitly not supporting multi-link subnets.

8) add language to the extensions draft reinforcing the length parameter's use, non-null termination of strings, and that byte- or word- alignment is not a requirement.

9) change draft language to allow relay agents to modify messages in flight, but add strong cautionary language concerning the implications to authentication and integrity checks.

10) solicit group input on client behavior in the case of 'transaction failure'. In the meantime, provide human-interpretable feedback that maps directly to the possible 'bad' status values.

11) remove sections of the protocol draft specifying authentication behavior, and replace with a reference to the DHCPv4 authentication draft. Add language to the extensions draft making the translation from DHCPv4 'options' to v6 'extensions' to support the authentication draft, and add language concerning message fields that must be zeroed for integrity checks. This includes specific language dealing with the DHCPv4 relay agent option (currently draft).

12) create 'Protocol State Diagrams'.

13) add the protocol version extension to the extension draft.

14) ALL CONCERNED GROUP MEMBERS: study the draft (if not already done), and prepare a list of concerns, suggestions and expectations. Prepare for an interim meeting, either in person or via conference call, towards the end of August, 2000. AUTHORS: consider methods of 'outreach' in order to get quality feedback in sufficient quantity. Ralph has offered to consult with the authors on ways to do this.


Dynamic Registration and Configuration Protocol (DRCP)
Kerberos V Authentication Mode for Uninitialized Clients
DHCPv6 Agenda