NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 06-Jul-99
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:
DHCP-DNS interaction: dhcp-dns@bucknell.edu DHCP implementions: dhcp-impl@bucknell.edu DHCP bake-offs: dhcp-bake@bucknell.edu Failover protocol: dhcp-serve@bucknell.edu DHCPv6: dhcp-v6@bucknell.edu DHCPv6 implementations: dhcp-v6impl@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:
· Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
· Interaction between DHCP and DNS
· Authentication for DHCP Messages
· Extensions for the Dynamic Host Configuration Protocol for IPv6
· The User Class Option for DHCP
· DHCP Relay Agent Information Option
· Multicast Address Allocation Configuration Options
· The Server Selection Option for DHCP
· The Domain Search Option for DHCP
· DHCP Continuation Option Code
· The Autonomous System Option for DHCP
· The Server Range Option for DHCP
· Security Requirements for the DHCP protocol
· Dynamic Host Configuration Protocol (DHCP) Server MIB
· DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
· Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network
· DHCP Use of the User Class Option for Address Assignment
· The Subnet Selection Option for DHCP
· DHCP Options for Call Control Servers
· The Name Service Search Option for DHCP
· New Option Review Guidelines and Additional Option Namespace
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 |
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 |
RFC2489 |
Procedure for Defining New DHCP Options | |
RFC2610 |
PS |
DHCP Options for Service Location Protocol |
The DHC working group met twice in Oslo. The first meeting was used for discussion of DHCPv4 issues. Thanks to Stuart Cheshire for taking notes for these minutes. Here is a summary of discussion
items and resolutions:
· DHCP authentication, Droms (for Arbaugh): Droms reviewed most recent draft. WG asked for revision: describe authentication for DHCPRELEASE, develop PKI example (Olafur Gudmundsson?), other minor fixes (to be submitted by WG). After revision is submitted, new draft will be submitted for WG last call.
· DHCP authentication, Gupta: reviewed recent draft proposing "protocol 2" for Droms/Arbaugh authentication. Gupta proposal is a generalization of the Droms/Arbaugh mechanism that supports public keys and roaming; new features include:
- Support for PK authentication
- Replay counter field replaced with replay-detection field
- MAC field replaced with authenticator field which may contain PK signatures as well as shared-key MAC
- In response to question about merging Droms/Arbaugh and Gupta protocols, WG consensus is to leave as two separate protocols. Droms/Arbaugh will review Gupta proposal to determine if modifications to packet format are warranted to accommodate Gupta "replay detection method" field.
· Name service search order, Smith: reviewed recent draft proposing new option for specifying name service search order; e.g., NIS+, NIS, DNS. WG reacted favorably and asked for final draft that will be submitted for WG last call.
· DHCP-DNS interaction, Stapp: reviewed changes in recent draft: added optional use of DNS encoding for FQDN, clarified administrators' options in deployment, tightened and clarified language, revise key RR protocol. Narten raised issue of obtaining key RR number; he and Stapp will obtain number and then go to last call within a month.
· DHCP failover protocol, Volz: reveiwed changes in most recent draft; most significant is exclusive use of TCP. Kinnear will schedule teleconferences for: TCP, load balancing, security over next month to finish draft before Washington IETF.
· LDAP schema for DHCP, Volz: reported on most recent revision to LDAP schema draft. Volz noted that the schema has several shortcomings that a policy-oriented schema might eliminate. Yet, a policy-oriented schema would be rather difficult to map to current servers. He sees three alternatives for moving forward:
1) continue with current direction;
2) move to more policy-based model;
3) scale back to record only lease information and not configuration information. Discussion to continue on mailing list.
· DHCP over IEEE 1394, Fujisawa: reviewed recent draft. Fujisawa explained key architectural issue that affects use of DHCP: node IDs can change at any time; e.g., whenever new device is plugged into bus. Thus, node ID cannot be used for client's hardware address and for client identification. WG discussed use of EUI-64, UUID as client identifier and client hardware address for DHCP. Issues will be taken to mailing list for further discussion.
· Futures panel, Droms (for Carney): reviewed recent draft report from futures panel. No comment from WG; will report to Carney and determine if draft needs further revision before WG last call.
· WG administrative details, Droms:
- WG agreed to collapse all DHCP mailing lists into two lists: dhcp-v4 and dhcp-v6
- No support for user class option; will confirm with message to mailing list and then remove from WG charter
- Bill Sommerfield agreed take over server selection option
- Mark Stapp agreed to complete option code recovery process
The second WG meeting was used for discussion of recent developments in DHCPv6 process:
· Mike Carney has agreed to become an author of the documents. He will have control of the documents' sources.
· Mike, Jim and Charlie plan to have a revision to the documents complete by the Washington IETF.
· The WG agreed on the following plan for completion of the documents:
- Develop list of issues to resolve; obtain WG consensus that list is as complete and appropriate as possible
- Develop solutions to issues from list; obtain WG consensus that solutions are correct
- Revise document based on solutions
- Obtain WG consensus that solutions are captured in revisions to specification
- Revise document for WG last call
- WG last call
· The WG developed an expanded list of goals and delivery target dates;
- List of issues: 8/15/99
- Solutions to issues: 10/ 1/99
- Revised draft: 11/10/99 (Washington IETF)
- Consensus on solutions
- Revised draft: 3/ 1/00 (Australia IETF)
- WG last call
· The WG developed the following list of issue areas and developed issues in each area. The areas are:
- Current technical issues
· Undiscussed issues from Minnesota WG meeting
· Unresolved issues from WG last call
· Releasing resources: too many alternatives?
· (Section 6) Is the mandate for implementation strategy too strong? Why is XID transaction cache described in such detail?
· Which messages are not idempotent (and why not)?
· How does a client request addresses from multiple prefixes?
· Does the RECONFIGURE mechanism scale w.r.t ACK implosion? New RECONFIGURE reduces messages from 2N to N, but N may still be large.
· In case of a RECONFIGURE failure, loosen text to specify "notify administrator" (rather than "log to error log").
· (Section 6.3.2) Clarify that 'C' bit semantics are to release all resources, reallocate only those requested in message.
· (Section 6.4) What does client do with response; add MUST/SHOULD.
- DHCPv4 features to carry forward/misfeatures to avoid/missing features to add
· Extensibility framework: accommodate future extensions without requiring recoding/redeployment of clients
· Vendor identifier/vnedor-encapsulated options
· "Echo option" - client retains and echoes option value from server
· Explicit "change server" mechanism
· Client version option
- DHCPv4 current work to review
· Agent options
· Failover protocol: any features in base DHCPv6 spec that would make inter-server protocol easier to write?
· DHCP-DNS interaction
- DHCPv6 new features
· What must client do to support interaction with applications?
· Consistency across client implementations:
- List of client-supported options
- Client can explicitly reject options as unsupported/unrequested
- Alternative actions: what to do if option unrecognized, unrequested, ...
- Requested values: client gives range of desired values
· Model of "resources" and client-server management; what's the "right" model?
- What is a "resource"?
- What is "releasable"?
· How does renubmering work; e.g., through RECONFIGURE?
- Document structure
· Organization - unclear when reading; information duplicated, not in same part of document, contradictory. Mike Carney to add protocol overview
· Additional discussion needed about why complicated actions are mandated and how they were arrived at. WG to send input to authors about parts of the spec that require additional discussion.
· Consider merging two documents into one.
None received.