(Back to dhcp.org home)
(Back to 12/00 meeting page)

Minutes from the DHC (Dynamic Host Configuration) working group meetings
in San Diego, CA

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
   s 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 this option should be assigned suboption code 4.

   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/15/2001
Teleconference                               2/12/2001
Rev -18 of spec (if necessary) or last call  2/28/2001
WG review or last call                       Minneapolis
                                             3/xx/2001