Dynamic Host Configuration (dhc) From: Ralph Droms Droms - WG activities: summary of recent RFCs and I-D status Beser, DHCP Option for PacketCable VoIP - needs additional clarification; WG will consider future drafts Kinnear, DHCP Failover Protocol - draft is on schedule for last call after Minneapolis IETF Kinnear, Lease query - Described purpose and operation of option. Will revise draft to address comments and security. Waters, DHCP Server MIB - MIB I-D updated and to be reviewed by "MIB docs"; will come back to WG after revision Woundy, Device class agent option - WG will consider future revisions Volz, Load balancing - I-D now with IESG Lemon, Classless static routes - Ready for WG last call after next revision 9to be published w/in one week) Lemon, DHCP authentication w/ Kerberos - Will collaborate with authors of Medvinsky authentication draft Tsirtsis, AAA from DHCP relay agents - Others with interest from WG will join authors in revising I-D; Droms to draft WG charter item to investigate DHCP/AAA integration Aboba, DNS search option - Will revise draft to describe carefully use of DNS name compression with multiple instances of DNS search option; read for WG last call Medvinsky, DHCP authentication w/ Kerberos - (see Lemon) Meeting 2============================================== 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 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 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/31/2001 Teleconference 2/12/2001 Rev -18 of spec (if necessary) or last call 2/28/2001 WG review or last call Minneapolis