(Back to dhcp.org home) (Back to 7/99 meeting page)

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.