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.
