Subject: Minutes from DHC WG meetings in San Diego (REMINDER!!)

From: Ralph Droms <[email-masked]>
Date: Fri, 05 Jan 2001 08:49:54 -0500

(Note that there is a small change to the notes about the "Addition of 
Device Class to Agent Options" I-D; see change bars. - RD)

Included below is a draft of the minutes from the San Diego 
meetings.  Please get back to me by the end of next week (1/5) if you have 
any additions, corrections or other questions.

- Ralph

=====

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 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 [email-masked]

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
                                              3/xx/2001

---

From: "Thirumalesh Bhat" <[email-masked]>
Date: Fri, 5 Jan 2001 11:59:34 -0800

Ralph, thanks for compiling the minutes and sending them to the
dhcpv4 mailing list. 

	I have a comment on the DHCPv6 drafr. Would it make sense to
combine multicast address allocation with generic IPv6 address
allocation? In the IPv4 world, we have different protocols ( MADCAP -
RFC 2730 )for multicast address allocation. Since in IPv6, multicast is
going to be more critical than in IPv4, a unified protocol would serve a
better purpose.

thx

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Friday, January 05, 2001 5:50 AM
To: DHCPv4 discussion list
Subject: Minutes from DHC WG meetings in San Diego (REMINDER!!)

Included below is a draft of the minutes from the San Diego 
meetings.  Please get back to me by the end of next week (1/5) if you
have 
any additions, corrections or other questions.

- Ralph

=====

New RFCs:

I-D Actions and Status:

DHCPv6 Activities:
* Teleconference 8/31
   List of issues generated

    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.

DHCP Lease Query
Kim Kinnear

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

    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

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

Issue:    Authentication

New schedule:

---

From: Bernie Volz <[email-masked]>
Date: Sat, 6 Jan 2001 20:49:26 -0500

I do think that this has some merit. Though I myself haven't looked at the
MADCAP protocol.

I think the best way to proceed is let us 'finish' DHCPv6 for address
allocation (since we'd like to do this by about the Spring '01 IETF
meeting). Please do look at the current work and make comments to the list
if you see things that would prevent it working for multicast allocations.
Once the base work is complete, additional options can be defined to support
multicast allocations.

- Bernie Volz

-----Original Message-----
From: Thirumalesh Bhat [mailto:[email-masked]]
Sent: Friday, January 05, 2001 3:00 PM
To: DHCPv6 discussion list
Cc: Matthew Williamson; Stephen Bensley
Subject: RE: Minutes from DHC WG meetings in San Diego (REMINDER!!)

thx

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Friday, January 05, 2001 5:50 AM
To: DHCPv4 discussion list
Subject: Minutes from DHC WG meetings in San Diego (REMINDER!!)

- Ralph

=====

New RFCs:

I-D Actions and Status:

DHCPv6 Activities:
* Teleconference 8/31
   List of issues generated

DHCP Lease Query
Kim Kinnear

DHCP failover protocol
Kim Kinnear

Issue:    Authentication

New schedule:

---

From: Ralph Droms <[email-masked]>
Date: Sun, 07 Jan 2001 12:23:48 -0500

At 11:59 AM 1/5/01 -0800, Thirumalesh Bhat wrote:
>Would it make sense to
>allocation?

The WG chose not to include multicast address allocation in DHCPv4 because 
it seemed different enough from unicast allocation to warrant an 
independent protocol.  We can certainly review multicast address allocation 
in DHCPv6 - a good place to start would be a mailing list discussion...

- Ralph