Current Meeting Report

2.2.3 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 29-Jan-02
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
RFC3203PSDHCP reconfigure extension

Current Meeting Report

Droms, DHCP to Full Standard
Ralph suggested the WG take on the task of moving DHCPv4 to full standard. This task would include minimal rewrites to correct and clarify known problems and collect "lore" associated RFC2131/2132, and collect all options into RFC2132. Ted Lemon said collecting all the options into RFC2132bis would be a bad idea because of the size of the resulting doc and the potential for objections. Kim Kinnear pointed out that the options are not all at Draft Standard (where RFC2131 and RFC2132 are today). Ted and Mark Stapp said that operational issues belong in a BCP and not in the base specification RFCs. Thomas Narten asked if this is the best use of WG resources? He suggested the WG focus on revising the WG charter and prioritizing the outstanding tasks before selecting any particular task. Droms will lead a discussion of the WG charter on the mailing list.

Henrik Levkowetz
DHCP Option for Mobile IP Foreign Agents
The draft defines a new option pption to specify MIP foreign agent address. That FA address is currently discovered by broadcast. The WG agreed to take on the document as a WG work item.

Ted Lemon/Carl Smith
Considerations for the use of the Host Name option
Ted and Carl began with a series of questions about the use of the hostname and FQDN options.

The key issues in the draft are:
- Authentication of DHCP client and proxy updates through DHCP server
- Impact on FQDN option; e.g., use FQDN to delete existing name
- Interaction of existence of FQDN and hostname options (for backward compatibility)

This draft may impact the FQDN/DDNS drafts. The authors will continue working on the document.

Josh Tseng
DHCP Options for Internet Storage Name Service
Review - ISNS is information (naming) repository for IP storage devices. DHCP will be important for configuration of iSCSI devices. ISNS can also be located through SLP; there are examples of other services that can be located through SLP and configured through DHCP. The chair of the IP Storage WG confirmed that WG's support for this draft. The DHC WG agreed to take on the draft as a work item.

Bernie Volz
Load Balancing for DHCPv6
New draft based on feedback from discussion in SLC. Applies to messages not directed to a specific server. Uses DHCPv6 recovery if target (based on load balancing) is down. Uses hash algorithm from RFC 3074. Next step: review and comment from WG.

WG comments:
- Relay agent can support load balancing
- Draft could use more motivation
- Draft could use more on potential configurations
- If the server DUID is not present, the relay agent should not do load balancing.

John Schnizlein
RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option

This document is now a working group draft. The motivation is AAA server, not 802.1x, so this draft now focuses on authentication service; it can use any RADIUS-based identity/authentication information.

One potential security issue is impostor fabrication of DHCPDISCOVER with an RA option. The currrent draft uses an implicit trust relationship between AAA server and DHCP server (a shared key) through which the AAA and DHCP server can communicate signed information.

The WG a\greed to take on the problem of authenticating messages between the relay agent and the server.

Kim Kinnear
DHCP Lease Query
The most recent rev of the draft has been significantly reorganized.
There are new reply messages (KNOWN/UNKNOWN/ACTIVE); fixes, clarifications to reservation handling; Redefined dhcp-requested-address option to return multiple IP addresses. Ready for last call? Yes.

Subnet Selection sub-option for the Relay Agent Information Option

This spec has gone through WG last call. One issue has appeared in last call review. In the subnet selection option spec, the server returns the option only if it actually used the option. Howver, the server is required to return all realy agent options, so the relay agent can;t determine if the server actually used the subnet selection usboption.

- Ignore the problem; wait for phone call to notice problem.
- If relay agent doesn't get subnet selection sub-option, will drop packet and client won't get DHCP reply

Results of WG discussion
1. Remove words that say client should not use option if not included in response to option and suboption
2. Remove words that say server should send option if used in selection
3. Add text that says client MUST NOT use presence or absence of option or suboption in determining if option was used

IPv6 Prefix Options for DHCPv6
This option allows an ISP router to delegaett prefixes to a CPE.
There are several open issues:
- two message exchange for static prefixes
- use of ipsec for authentication of these requests (rather than dhc authentication)
- name issues: "dynamic", "host"
- lemon: what about redundant routers..
Ralph will take the open issues to the WG mailing list.

Using DHCPv6 for DNS Configuration in Hosts
The -01 rev has more information on how to implement the proposed DNS configuration mechanism. Ralph said the authors are considering publishing the draft as an informational RFC.

Vijayabhaskar A K
DHCPv6 (rev -23) Issues
Vijay will publish drafts defining proposed options.

Suggestion: Should there be a separate XID range to avoid redundant retransmission after Reconfigure-Init; WG has considered this idea and has decided not to use it.

Suggestion: Should there be separate IAs for normal and temporary addresses. How can client indicate to server that it no longer wants normal addresses? Vijay will post query to mailing list.

Question: Is there a potential conflict between address selection and "Default Address Selection" RFC. (A) There is no conflict because there is an explicit API in the advanced API spec for explicit source selection.

Editorial: Some error codes not used anywhere; will be removed.


DHCP Option for Mobile IP Foreign Agents
DHCP Lease Query
Using DHCPv6 for DNS Configuration
IPv6 Prefix Delegation Options for DHCPv6
Proposal for DHCP Option for iSNS
subnet-selection sub-option