2.3.3 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 28-Nov-00

Chair(s):

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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

RFC1534

DS

Interoperation Between DHCP and BOOTP

RFC1542

DS

Clarifications and Extensions for the Bootstrap Protocol

RFC2132

DS

DHCP Options and BOOTP Vendor Extensions

RFC2131

DS

Dynamic Host Configuration Protocol

RFC2241

PS

DHCP Options for Novell Directory Services

RFC2242

PS

Netware/IP Domain Name and Information

RFC2485

PS

DHCP Option for The Open Group's User Authentication Protocol

RFC2610

PS

DHCP Options for Service Location Protocol

RFC2939

  

Procedure for Defining New DHCP Options and Message Types

RFC2937

PS

The Name Service Search Option for DHCP

RFC3004

PS

The User Class Option for DHCP

RFC3011

PS

The Subnet Selection Option for DHCP

Current Meeting Report

First Meeting
Dynamic Host Configuration (dhc)
From: Ralph Droms <rdroms@cisco.com>
Droms - WG activities: summary of recent RFCs and I-D status

Beser, DHCP Option for PacketCable VoIP - needs additional clarification; WG will consider future drafts

Kinnear, DHCP Failover Protocol - draft is on schedule for last call after Minneapolis IETF

Kinnear, Lease query - Described purpose and operation of option. Will revise draft to address comments and security.

Waters, DHCP Server MIB - MIB I-D updated and to be reviewed by "MIB docs"; will come back to WG after revision

Woundy, Device class agent option - WG will consider future revisions

Volz, Load balancing - I-D now with IESG

Lemon, Classless static routes - Ready for WG last call after next revision 9to be published w/in one week)

Lemon, DHCP authentication w/ Kerberos - Will collaborate with authors of Medvinsky authentication draft

Tsirtsis, AAA from DHCP relay agents - Others with interest from WG will join authors in revising I-D; Droms to draft WG charter item to investigate DHCP/AAA integration

Aboba, DNS search option - Will revise draft to describe carefully use of DNS name compression with multiple instances of DNS search option; read for WG last call

Medvinsky, DHCP authentication w/ Kerberos - (see Lemon)

The DHC WG met twice in San Diego. The WG discussed DHCPv4 issues in the first meeting:

Ralph Droms (chair) opened the meeting with a summary of recent WG activities and document publications:

New RFCs:
* Procedure for Defining New DHCP Options and Message Types (RFC2939)
* The Name Service Search Option for DHCP (RFC2937)
* The User Class Option for DHCP (RFC3004)
* The Subnet Selection Option for DHCP (RFC3011)
* DHCP Relay Agent Information Option (Accepted for Proposed Standard)

I-D Actions and Status:
* Authentication for DHCP Messages: republished; requires minor edits before submission for Proposed Standard
* Dynamic host configuration : DHCP reconfigure extension: ready for submission for Proposed Standard; awaiting authentication draft
* Several new drafts to be considered for WG action

DHCPv6 Activities:
* Teleconference 8/31
List of issues generated
Solutions added to spec I-D
Discussion on mailing list
* -16 rev of I-D published
* Teleconference 12/5
Issues in -16 rev
Some solutions defined
Some issues to be discussed in WG meeting
* WG meeting on DHCPv6 12/12

DHCP Option for PacketCable VoIP Client Configuration
Burcak Beser

In packet cable equipment, there may be multiple personalities within a single device such as a VoIP device. Each personality may need a separate IP address and obtain that address through a different DHCP server. Beser's draft, draft-ietf-dhc-packetcable-01.txt, proposes a new option that would support the PacketCable standard for configuring a DHCP server in a packet cable device. The WG asked if it is necessary for packet cable devices to have an architecture with multiple personalities that is configured with a special option. Kim Kinnear clarified that this option will support the standard of another standards body (PacketCable) without mandating its use by all DHCp clients. There was another question about the use of unicast versus multicast, which was clarified by pointing out the the initially configured packet cable device can act as a relay agent for the second device and unicast messages directly to the second level DHCP server.

Action item: Beser will redraft to clarify format of options. Droms will review use of option specific to packet cable devices with PacketCable standard.

DHCP Lease Query
Kim Kinnear

Issues with current draft, draft-ietf-dhc-leasequery-00.txt:

Security - Kinnear suggested configuration of server with list of acceptable queriers would be an acceptable solution.

Bulk, subnet-basis query - Kinnear has investigated bulk queries, but of the opinion that the extra complexity does not justify the efficiency gain.

What has Cisco implemented - In response to query from Ted Lemon, Kinnear will post summary of current Cisco implementation to DHC WG mailing list.

Lease query and failover - Bernie Volz suggested draft should discuss use of lease query with failover partners; Kinnear agreed to add text to the draft about failover.

Reservation - Kinnear will add bit to message to explicitly identify reservations.

Different message types - Lemon suggested new message types rather than ACK/NAK. Kinnear agreed to this change.

Action items: Kinnear will revise draft according to changes discussed during WG meeting. WG will review new draft at next meeting (Minneapolis) and then draft will go to last call.

DHCP failover protocol
Kim Kinnear

Kinnear discussed what changed in most recent draft,
draft-ietf-dhc-failover-08.txt. Lemon suggested we do
interoperability testing between two independent implementations.
Richard Jones said he would have an implementation by late January.

Action item: Draft to go to last call prior to Minneapolis (either -08
or -09 draft at authors' discretion).

Addition of Device Class to Agent Options
Rich Woundy

Woundy describes a new relay agent suboption in draft-ietf-dhc-agentoptions-device-class-00.txt. The new suboption allows the relay agent to identify the device class to the DHCP server. Lemon pointed out that suboption code 3 should not be used and new options should be assigned suboption code 4. Current draft specifies suboption code 4 but will be revised to TBD.

Action item: Author will resubmit and WG will review new draft.

Dynamic Host Configuration Protocol (DHCP) Server MIB
Glenn Waters

Waters announced that the DHCP server MIB in draft-ietf-dhc-server-mib-05.txt will be reviewed by the MIB doctors and then will be ready for last call.

Action item: Authors to submit draft to MIB doctors and then draft (revised if necessary) will got to last call.

DHC Load Balancing Algorithm
Bernie Volz

Now at IESG for last call.

The Classless Static Route Option for DHCP
Ted Lemon

Action items: Lemon to clarify draft. Revised draft then ready for last call.

DHCP Domain Search Option
Bernard Aboba

Issue of DNS compression as "evil" was raised. In this option, because compression reference point is well-known (beginning of option), compression is not a problem.

Action items: Lemon to write draft describing concatenation of DHCP options. Aboba to revise draft to reference Lemon doc. Domain Search Option draft then ready for last call.

DHCP Authentication Via Kerberos V
Ted Lemon

Lemon opined that this draft is the Kerberos-based authentication scheme that is the most likely to be deployed. Droms suggested that a quick summary of the differences between this scheme and the Lalwaney-Smedvinsky scheme would be useful; Lalwaney-Smedvinsky draft has such a comparison. See notes on Lalwaney-Smedvinsky draft (below) for more information.

Triggering AAA from DHCP Relay Agents
George Tsirtsis

This draft describes a mechanism in which relay agents use AAA to validate DHCP request. Draft triggered discussion about whether this issue is within DHC WG charter. WG consensus is that it *should* be.

Action items: Author to revise and WG will consider draft. Droms to add AAA/DHCP interaction to WG charter.

Kerberos V Authentication Mode for Uninitialized Clients
Sasha Medvinsky

The Lalwaney-Medvinsky scheme for Kerberos-based DHCP authentication involves the use of "Kerberos Proxy' that assists a Kerberos exchange before the DHCP message exchange.

Action item: Authors of two Kerberos authentication drafts will meet to devise single scheme to bring to WG.

The WG discussed DHCPv6 issues in the second meeting:

* Recent protocol spec activities:
- 8/31 teleconference
- Publication of draft-ietf-dhc-dhcpv6-16.txt based on issues resolved in 8/31 teleconference
- 12/5 teleconference

The following people participated in the 8/31 teleconference:

Ralph Droms, Mark Stapp, Rich Woundy, Michael Carney, Jim Bound, Bernie Volz, Richard Jones, Thomas Narten, Ted Lemon, Barr Hibbs, Bernard Aboba, Richard Johnson, Josh Littlefield, Subir Das, Tony McAuley, Franics DuPont

The group identified the following changes to be made in DHCPv6 spec; Droms presented this list to the WG and the WG accepted the changes except where noted:

Issue: Understanding spec requires reading two documents
Solution: Combine protocol spec and definitions for options that are part of base protocol operation into single document

Issue: Releasable resources defined in DHCPv6; only real example is IPv6 addresses
Solution: Discard all references to releasable resources and refer only to IPv6 addresses
WG discussion: What about IPv4 addresses? Should IPvn addresses be carried on;y in DHCPvn; i.e., a dual-stack client uses both DHCPv4 and DHCPv6?

Issue: Address model needed to allow for multiple addresses on an interface, multiple interface, roaming client identification
Solution: define "Identity Association" to be a labeled collection of addresses
Outstanding issues:
- How to label?
- Semantics of address management
WG discussion: Additional discussion reserved for end of WG meeting

Issue: Client behavior for address lifetime extension undefined
Solution: Added description of address lifetime extension through IAs, controlled by parameters T1 and T2

Issue: Cleaner and simpler message formats
Solution: Redefined message headers; all messages share same header format
Related: Servers no longer advertise prefixes
WG discussion: What about prefix advertisements if not in a routed environment? Consensus in WG was that prefixes not needed in this case.

Issue: What were called "options" in DHCPv4 are called "extensions" in DHCPv6
Solution: Rename "extensions" to be "options"

Issue: Where appropriate, coordinate DHCPv4 and DHCPv6 options (e.g., option codes, data formats, specifications)
Solution: TBD

Issue: Reduce number of ways to release addresses
Solution: Release message is only way to release addresses

Issue: Simplify reconfiguration
Solution: Use DHCPv4-style reconfiguration; include multicast reconfiguration with no reliability guarantees
WG discussion: When using multicast reconfigure, should reconfigure message be multicast once or more than once. If the server has a list of the clients it is trying to reconfigure, the server can manage retransmission for reliability. However, if the clients are not using DHCP for address assignment (i.e., using DHCPINFORM-like function), server may not have a list of clients. In any event, clients must be able to detect duplicates and respond (or not respond) appropriately.

To mitigate "multicast implosion" due to synchronized responses to multicast reconfigure messages, Erik Nordmark suggested including delay parameters in the reconfigure message. This new parameter would specify a random delay to be used by clients to spread out the responses sent to the server.

Issue: Authentication
Solution: Use DHCPv4-style authentication framework

Issue: Relay agents function (carried forward from BOOTP) is cumbersome
Solution: Use encapsulation, in which client message is carried as payload in relay agent message

Issue: Clients unicast some messages and multicast others (on local link)
Solution: Clients multicast Solicit and Request messages; are not required to explicitly learn of relay agents
WG discussion: Consider control from server to require client to multicast all messages, which would enable relay agents to examine all client messages. Draft will be left as is; if all-multicast mode is desired, text will be drafted and added to the spec before last call

Issue: Avoid stateful server operation so that correct server operation does not depend on XID
Solution: Redefined message exchanges so that server always returns same reply to retransmitted client message

Details of -16 Rev of Spec I-D
* Implemented solutions from 8/32 teleconference
* Published just before I-D cutoff
* Lots of typos; report them off-line to rdroms@cisco.com

There was another teleconference of 12/5 to discuss the 16 rev of the protocol spec. The following people participated in the 12/5 teleconference: Michael Carney, Jim Bound, Bernie Volz, Thomas Narten, Ted Lemon, Ralph Droms, Mark Stapp, Kim Kinnear, Matt Williamson, Mike Dooley, Vijaya Bhaskar

Here is a list of issues and resolutions from the 12/5 teleconference; again with any WG discussion or outstanding issues:

Issue: Definition of label for IA
Solution: Define UUID - "Universally Unique IDentifier" for each client; client assigns label to each IA: (UUID, binding-id)
Outstanding issues: How is UUID defined? How does server use UUID to identify an IA? Volz suggested the identifier should be called DUID - "DHCP Unique IDentifier". More discussion deferred to end of WG meeting.

Issue: Should Advertise message include addresses and configuration parameters from server?
Solution: Yes
WG discussion: Jim Bound asked if DHCPv4 semantics, in which server must mark offered address for later assignment to the client, must be adhered to. Droms believes this is an implementation issue not specified in the DHCPv4 spec. Kinnear suggested that if the client explicitly wants the addresses from the Advertise message, there should be an option through which it can request those addresses.

Issue: What additional options should be included in base protocol spec or in separate doc?
Solution:
- Base spec: Status code, DHCP operational parameters (timeouts, etc.)
- Separate doc: DNS name, DNS search order, DNS servers, client class, vendor class, TFTP server, boot file name, static routes
Outstanding issues: Base spec or separate doc? Others options?
WG discussion: Kinnear suggested that the base spec doc should include a definition of standard data types for use in future options. Droms said he would put framework and data types for option definitions in base spec.

Kinnear suggested relay agent option numbers should come from the same number space as client option numbers. There was some discussion about this suggestion but no consensus about a resolution.

Issue: Should client be allowed to include requested or preferred option values in Solicit message?
Solution: Yes.
WG discussion: Lemon wants to allow clients to request specific options but not values for those options. Richard Jones suggested placing general prohibition on requesting specific values but allowing exceptions for individual options, to be specified in option spec. Lemon also suggested that option specs should clearly articulate what it means when a client and a server sends the option.

Issue: What about DDNS-DHCP interaction?
Solution: Apply current specs to DHCPv6 as well; not required for base spec
Outstanding issues: Is the current spec adequate; what options are needed?
WG discussion: Mark Stapp will be asked to extend current DDNS-DHCP interaction docs for DHCPv6.

Issue: Is merging DHCPDECLINE function from DHCPv4 into Release message a good idea?
Solution: No; define new Decline message

Issue: Does a DHCPv6 server need to differentiate between Request messages sent by client when initializing, confirming and extending address lifetimes?
Solution: Yes; define different messages for each situation

Issue: What if there is more than one relay agent on a link and the client receives multiple responses?
Solution: Make sure DHCPv4 operation is carried forward

Issue: Through what mechanism should an application communicate with the server?
Solution: TBD
WG discussion: There was an inquiry about whether the base spec should mention and API; no action for now

Issue: What authentication mechanisms need to be defined in base protocol spec?
Solution: Define authentication framework like DHCPv4; define one mandatory authentication protocol (e.g., DHCPv4 HMAC/shared-secret unless we can come up with something better)
WG discussion: In an IETF security briefing (previous day) Jeff Schiller said HMAC/shared-secret is good enough; check with security experts for something better.

WG discussion after review of -16 rev issues:

* Milestones/timeline TBD to get to last call before next WG meeting (Minneapolis); see below for final schedule

* Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list.

* Narten also raised issue of interaction between DHCP and temporary addresses. DHCP server can provide temporary addresses by assigning addresses with short lifetimes. However, there will be an API through which an application can request a temporary address. How can the DHCP server indicate to the client which addresses are to be "temporary" and which are "permanent"? Narten thinks IESG will bounce anything that doesn't deal with temporary addresses. He will develop requirements doc so WG can develop solution.

* IA identification in draft is based on tuple (UUID, binding-id). WG must develop rules for generating guaranteed unique UUID and whether server should also include link prefix with IA identifier. Lemon summarized his thoughts on generating UUID and will write a draft. Lemon will also write up requirements for UUID. Narten said UUIDs are in use elsewhere and we should research those other UUIDs. Discussion on IA identification will continue on WG mailing list.

New schedule:

Continue discussion of outstanding issues now
Rev -17 of spec 1/31/2001
Teleconference 2/12/2001
Rev -18 of spec (if necessary) or last call 2/28/2001
WG review or last call Minneapolis

Slides

None received.