2.3.5 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 07-Nov-97

Chair(s):

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 listname 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.

More information on DHCP and the DHC WG can be found at http://www.bucknell.edu/~droms/dhcp.

Other DHC Lists:

General Discussion: dhcp-v4@bucknell.edu DHCP-DNS Interaction: dhcp-dns@bucknell.edu Implementation issues: dhcp-impl@bucknell.edu Bakeoff events: dhcp-bake@bucknell.edu Inter-server protocol: dhcp-serve@bucknell.edu DHCP for IPv6: dhcp-v6@bucknell.edu Implementation issues for DHCPv6: dhcp-v6impl@bucknell.edu

Goals and Milestones:

Done

  

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

Done

  

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

Done

  

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

Done

  

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

Done

  

Develop options for automated registration in DNS.

Done

  

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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1534

PS

Interoperation Between DHCP and BOOTP

RFC1542

PS

Clarifications and Extensions for the Bootstrap Protocol

RFC2132

DS

DHCP Options and BOOTP Vendor Extensions

RFC2131

DS

Dynamic Host Configuration Protocol

Current Meeting Report

Minutes of the Dynamic Host Configuration (dhc) WG

I. DHCPv4

These minutes were compiled by Ralph Droms. Thanks to Barr Hibbs and Mike Patrick for contributing their notes from the meeting.

The WG chair, Ralph Droms, opened the meeting with some administrative details. The WG approved the user class option <draft-ietf-dhc-userclass-02.txt> to go to WG last call. The chair will make the announcement to the WG mailing list. There was some question about whether the service location protocol draft <draft-ietf-dhc-slp-02.txt> was ready for WG last call. The author, Charlie Perkins, and the chair will resolve the status of that draft. Sun is hosting "DHCP Connectathon 98" of DHCP clients and servers in San Jose March 4-12. This event may be of interest to many WG members. Last year 28 companies participated in Connectathon, and several interoperability issues were resolved.

In response to questions about future developments in DHCP and DHCP options, Droms proposed the formation of a "DHCP futures panel". This panel would put together an internet draft with recommendations on the development of new DHCP options and the effect those new options on deployed clients and servers. Droms will announce the formation of the panel to the WG mailing list, identify volunteers to participate on the panel, and, with WG input, develop a charge and timetable for the panel's activities.

DHCP-DNS interaction was discussed next. The current draft is stalled due to lack of consensus about whether servers should be allowed to perform DNS A record updates on behalf of the client. The WG did come to consensus that some form of DNS security is required for dynamic updates. The WG came to agreement that while the DHCP client SHOULD be one to update the DNS A record, in certain specialized cases a DHCP server MAY do so instead. In this case, the DHCP server MUST be sure of both the name to use for the client, as well as the identity of the client. Kim Kinnear agreed to develop examples of specific cases for inclusion in the DHCP-DNS interaction draft. The WG also arranged for interested parties to meet over lunch on Tuesday to continue the discussion.

Baiju Patel from Intel proposed using DHCP to get IPSEC tunnel configuration parameters. (draft-ietf-dhc-ipsec-dhcp-00.txt>. The problem is determining the IP address to use inside the tunnel. The proposed solution is to establish an IPSEC tunnel mode connection and then use DHCP within the tunnel to obtain IP address and other configuration parameters.

Bill Arbaugh from University of Pennsylvania presented a mechanism for DHCP client-server authentication using public key exchange. The details will be published in a draft soon. The mechanism provides secure mobility and fits within the existing DHCP model. There may be problems with carrying long certification keys in DHCP options and packets.

Walt Lazear of MITRE reported on some work in configuring routers using DHCP. The goal here is to automate the router configuration process in dynamic, low-bandwidth networks. Lazear identified three new options for router configuration: "autonomous system number," "BGP neighbors list" and "served IP address ranges." The WG expressed concern about the last option, but, in general, did not rule out further consideration of these options.

Mike Patrick of Motorola reviewed changes included in the latest revision of the agent options draft <draft-ietf-dhc-agent-options-03.txt>. These changes reflect input from the WG given after the Munich meeting.

Kim Kinnear of American Internet and Ralph Droms discussed the inter-server protocol. Prior to the meeting, Droms polled several WG members about the future of the inter-server protocol effort and the perception of the requirements an inter-server protocol must meet. This discussion contributed to the development of a new inter-server protocol proposal <draft-ietf-dhc-failover-00.txt>. Kinnear led off with a history of the inter-server protocol proposals and set the current situation. There are now two proposals on the table: a general-purpose protocol (Kinnear-Cole-Droms [KCD]) based on SCSP that can accommodate multiple servers per address pool and support automatic configuration of new servers, and a limited-purpose protocol (Grabil-Dooley-Kapur-Droms [GDKD]) that provides hot-backup reliability. The primary area of discussion was the possibility of duplicate address allocation. The KCD protocol eliminates any possibility of duplicate address allocation while the GDKD protocol may allocate the same address to different hosts under certain circumstances. The WG asked for a clear statement of purpose for the GDKD protocol, and the WG will need to answer several questions before deciding on one of these proposals:

Finally, Olafur Gudmundsson of TIS and Ralph Droms held a discussion about DHCP authentication. Before this meeting, Droms had polled several WG members about the authentication efforts. Droms and Gudmundsson presented a proposal to develop a series of DHCP authentication documents:

The WG expressed consensus to proceed with the development of these documents.

II. DHCPv6

These minutes were compiled by Ralph Droms.

Jim Bound (Digital) began the meeting with a report that the ngtrans WG is specifying DHCP as a way to avoid the use of NATs in IPv4-IPv6 transition.

The remainder of the meeting on DHCPv6 focused on a review of changes made to the DHCPv6 drafts in response to input from the WG meeting in Munich. Charlie Perkins (Sun Microsystems) began by describing the preferencing mechanism through which servers can control the choice of server made by a client.

Mike Carney (Sun Microsystems) asked why the transaction ID is specified as part of the binding. The consensus was that the transaction ID need not be part of the binding and will be removed in the next draft.

Several other issues, including the inclusion of the relay agent interface address in the REPLY message, allowing hard-coded server addresses as well as the all-servers-multicast address in relay agents, and addition of an explanation of known security vulnerabilities to the security issues section of the drafts were discussed.

Finally, the WG conducted a lengthy discussion about the interaction between addrconf and DHCP mechanisms. The issue arises from the effect of the router advertisement 'M' bit on addresses obtained through DHCP and the effect of prefixes marked as deprecated in router advertisements on addresses obtained through DHCP. The interaction is further complicated by the potential exploitation of the router advertisement as a denial-of-service attack through the insertion of bogus router advertisement messages, which would cause hosts to discard valid addresses. The interaction between DHCP and the Neighbor Discovery protocol will be defined by the addrconf working group and documented in the next revision of the Neighbor Discovery protocol specification. The text about the interaction in the DHCPv6 protocol specification will be replaced with a reference to the Neighbor Discovery protocol specification.

Slides

None Received

Attendees List

go to list

Previous PageNext Page