Current Meeting Report

2.2.3 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 30-Oct-01
Ralph Droms <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Thomas Narten <>
Mailing Lists:
To Subscribe:
Description of Working Group:
Other Lists:

A separate mailing list is used for discussing the IPv6 version of dhcp:

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:
RFC1534DSInteroperation Between DHCP and BOOTP
RFC1542DSClarifications and Extensions for the Bootstrap Protocol
RFC2132DSDHCP Options and BOOTP Vendor Extensions
RFC2131DSDynamic Host Configuration Protocol
RFC2241PSDHCP Options for Novell Directory Services
RFC2242PSNetware/IP Domain Name and Information
RFC2485PSDHCP Option for The Open Group's User Authentication Protocol
RFC2563PSDHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
RFC2610PSDHCP Options for Service Location Protocol
RFC2939 Procedure for Defining New DHCP Options and Message Types
RFC2937PSThe Name Service Search Option for DHCP
RFC3004PSThe User Class Option for DHCP
RFC3011PSThe Subnet Selection Option for DHCP
RFC3046PSDHCP Relay Agent Information Option
RFC3074PSDHC load balancing algorithm
RFC3118PSAuthentication for DHCP Messages

Current Meeting Report

DHC WG meeting, Salt Lake City

These minutes were prepared by Ralph Droms, based on notes from Ted Lemon and Stuart Cheshire.

DHC WG activities update, Ralph Droms

The DHCP FORCERENEW message, for server-initiated client configuration, has been published as RFC 3203.

The DHCP Failover Protocol spec <draft-ietf-dhc-failover-10.txt>, and Subnet Selection sub-option for the Relay Agent Information Option spec <draft-ietf-dhc-agent-subnet-selection-01.txt> are both ready for IETF last call.

Encoding Long DHCP Options <draft-ietf-dhc-concat-02.txt> and The Classless Static Route Option for DHCP <draft-ietf-dhc-csr-06.txt> are with the Internet Area Directors for submission to the IESG.

The DHCP Domain Search Option <draft-aboba-dhc-domsearch-08.txt> is ready for publication, awaiting publication of Encoding Long DHCP Options <draft-ietf-dhc-concat-02.txt> to resolve a normative reference. Thomas Narten pointed out that there is a serious security problem with configuration of the domain search list: an attacker might configure a host with a domain search list that can cause names to be resolved silently to unexpected targets; e.g., a reference to "my-webserver" would be resolved as "". Narten noted that DNSSEC can't solve this problem, as the DNS name (which points unexpectedly at the attacker host) is resolved correctly.

VPN Identifier sub-option for the Relay Agent Information Option <draft-ietf-dhc-agent-vpn-id-01.txt>, Kim Kinnear

Draft has no substantive changes; updates include an improved IANA considerations section and later expiry times. WG requested no additional changes prior to WG last call.

DHCP VPN Information option <draft-ietf-dhc-vpn-option-00.txt>, Richard Johnson

This option is essentially identical to VPN Identifier sub-option for the Relay Agent Information Option. WG requested no additional changes prior to WG last call.

DHCP Lease Query <draft-ietf-dhc-leasequery-02.txt>, Kim Kinnear

-03 draft was submitted but not published before IETF 52 due to mailer problems. The current draft needs to be revised slightly to support multiple queries in a single option, because this behavior is implied by Encoding Long DHCP Options <draft-ietf-dhc-concat-02.txt>. -04 draft should be ready for WG last call. Kinnear reported that there is a need to move quickly on this draft, as there are implementors waiting to find out the TBD values before completing implementations.

Dynamic Host Configuration Protocol (DHCP) Server MIB <draft-ietf-dhc-server-mib-07.txt>, Barr Hibbs

The latest draft includes minor revisions. Security has been made easier through the removal of ability to send some MIB elements. Many other simplifications, removing and simplifying variables deemed to be of limited usefulness. Next rev will be ready for WG last call.

DHCP Load Balancing Algorithm for IPv6, Bernie Volz

Volz proposed to extend DHCP load balancing to IPv6. Two questions: what should be used as the hash key and how should the servers behave when the client is not in the server's hash bucket? Narten said that the IESG was unhappy with the DHCPv4 load balancing behavior, in which a server drops requests not in its bucket, because there is no recovery mechanism in response to a server failure. Volz suggested that DHCPv6 load balancing set the server preference; Ted Lemon replied that the result would not be "load balancing". Volz to take the discussion to the mailing list.

IPv4 Address Conflict Detection <draft-cheshire-ipv4-acd-00.txt>,Stuart Cheshire

Cheshire's draft captures, precisely defines and clarifies address conflict detection in IPv4. This mechanism is used, for example, in the DHCP spec. Cheshire's goal is to document IPv4 address detection in one place to be referenced by other specs.

Kim Kinnear asked if this draft should be a DHC WG draft? Cheshire wondered if DHC is the right place, as other WG specs will reference his doc. Narten opined that DHC WG would be OK, as this WG has significant experience with the problem. Narten suggested that the document carefully document motivation for details such as timeouts, and document exceptions to SHOULDs and MUSTs.

Qualifying the Root Path Option for iSCSI Boot <draft-sarkar-dhc-iscsi-boot-00.txt>, Prasenjit Sarkar

Sarkar's draft describes a way to use the root-path option for passing a text string containing the IP address and target ID for iSCSI boot device. WG consensus was that proposed encoding fits within current definition of root-path option, so the encoding can be defined in the IPS WG document about iSCSI boot and no separate DHC WG document is required.

802.1X Credentials Sub-option for the DHCP Relay Agent Information Option <draft-droms-agentopt-8021x-00.txt>, John Schnizlein, Ralph Droms

Schnizlein and Droms have defined a new agent information suboption that carries 802.1x authentication credentials from a relay agent to a DHCP server. Once the 802.1x authentication has been completed and the port turned on, the relay agent can send the 802.1x authentication credentials to the DHCP server, which the DHCP server can then use, for example, to identify the DHCP client. WG agreed to take this spec on as a WG item. Authors to update draft, changing "credentials" to "identity information" and other changes based on WG input.

Use of the Host Name option for inferred DNS updates by DHCP servers, Carl Smith, Ted Lemon

Smith and Lemon proposed writing a document that specifies the relationship among and use of the Host Name option and the FQDN option for DNS updates by DHCP servers. The purpose of the document would be to capture current practice in a clarification and precise specification. The WG agreed to take this specification as a WG work item.

Dynamic Host Configuration Protocol for IPv6 (DHCPv6) <draft-ietf-dhc-dhcpv6-21.txt>, Jim Bound, Ralph Droms

WG discussed the -21 draft. Authors' plan is to revise spec based on input from WG and publish -22 draft. -22 draft will then be submitted for WG last call. Narten pointed out that 3GPP spec has normative reference to DHCPv6 and needs DHCPv6 spec by March, 2002.

Primary change in -21 draft is modification to text on identity associations. New text, with scoped options for addresses and identity associations, was discussed and accepted by the WG.

The authors asked for help with temporary addresses. Consensus from WG was to proceed with as simple a mechanism as possible: addresses are simply labelled as "temporary", with no additional statement in DHCP spec about lifetimes, extending lifetimes, etc.; client can request temporary addresses; server can assign temporary addresses.

Reconfigure now has a problem because of Inform message: currently, only a Request can satisfy an outstanding Reconfigure message from the server. Inform should also satisfy Reconfigure. Lemon pointed out that Inform can satisfy Reconfigure only if server hasn't assigned any addresses to the client; authors will revise text to reflect this observation.


None received.