• Current Meeting Report
• Slides
• Attendees List

Dynamic Host Configuration (dhc) 

Chair(s): 

Ralph Droms <droms@bucknell.edu

Frank Kastenholz <kasten@ftp.com
Jeffrey Burgan <jburgan@baynetworks.com

General Discussion:dhcp-v4@bucknell.edu
To Subscribe: listserv@bucknell.edu
Archive: ftp://ftp.bucknell.edu/pub/dhcp

This working group will produce a protocol for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. Specific functions to be included in the protocol include:

Automated allocation and recovery of IP addresses 
Automated configuration of all TCP/IP stack parameters, as described in the Host Requirements documents 
Automated registration with the DNS 
Automated configuration of other host parameters such as application layer services 
Inter-server communication for coordination of multiple servers

As part of the work in devising strategies to facilitate renumbering, the WG will coordinate with the work of the PIER WG, and will consider the recommendations of the PIER WG in the further development of host configuration mechanisms

A specification the Dynamic Host Configuration Protocol (DHCP) for IPv4 has been entered into the IETF standards track. As of 10/95, it has been submitted for acceptance as a "Draft Standard." The working group is also developing a specification for DHCP for IPv6 (DHCPv6), which is currently available as an Internet Draft. 

More information on DHCP can be found at: http://www.bucknell.edu/~droms/dhcp.

&middot; Dynamic Host Configuration Protocol

&middot; Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

&middot; DHCP Options and BOOTP Vendor Extensions

&middot; Interaction between DHCP and DNS

&middot; Authentication for DHCP Messages

&middot; An Extension to the DHCP Option Codes

&middot; An option for FQDNs in DHCP options

&middot; Extensions for DHCPv6

&middot; DHCP Options for Service Location Protocol

&middot; The User Class Option for DHCP

&middot; DHCP Option for IEEE 1003.1 POSIX Timezone Specifications

&middot; An Inter-server Protocol for DHCP

&middot; DHCP Agent-Supplied Options

&middot; Multicast address allocation extensions options

&middot; Multicast address allocation extensions to the Dynamic Host Configuration Protocol

&middot; DSCP: Dynamic Subnet Configuration Protocol

&middot; The Server Identification Option for DHCP

&middot; The Server Selection Option for DHCP

&middot; Security Architecture for DHCP 

&middot; An Inter-server Protocol for DHCP

Minutes of the Dynamic Host Configuration (DHC) Working GroupThe DHC Working Group met for four one-hour sessions. One session was used for each of the following: old business, DHCPv6, new business, and ongoing discussion.Note that all internet draft names in these minutes are published with the "draft-ietf" prefix and ".txt" suffix elided.

Glenn Stump discussed three related options: user class (dhc-userclass-01), server selection (dhc-sso-00), and server identification (dhc-sio-00) options. The Working Group agreed that the user class option could be considered for Proposed Standard. Glenn agreed to write a BCP document to accompany the server selection and server identification options prior to review for submission as Proposed Standards.

Ralph Droms asked for comments on the most recent version of the DHCP-DNS interaction document (dhc-dhcp-dns-03). There were concerns raised about the requirement that a DHCP server wait until the DNS update completes before responding to the DHCP client; this delay may cause significant performance problems. The Working Group asked for the following revisions:

&middot; Allow the DHCP server to respond to the client without waiting for the update

&middot; Additional response code to indicate DHCP server timed-out waiting for the DNS update to complete 

&middot; Additional words about administrative control; e.g., DHCP server may want to do all updates within its domain, but allow the DHCP client to do updates on names outside the server's domain.

Michael Patrick spoke about the agent options (dhc-agent-options-00):

&middot; Circuit ID (identifies the circuit to which the DHCP client is attached; used for reverse routing back to the client)

&middot; Remote ID (additional identifier for the remote agent) 

&middot; Subnet mask (used to pass the subnet mask for the client from the remote agent to the DHCP server)

The Working Group raised authentication as an issue; any options added by the remote agent would not be included in a message digest computation from the DHCP client. There are also some details to be worked out about whether a client can insert agent options and whether the remote agent should strip any agent options out of DHCP messages returned to the DHCP client.

Charlie Perkins discussed the Service Location Protocol option. The Working Group asked that the option be extended to carry FQDNs as well as IP addresses; otherwise, the option is ready for Proposed Status.

Ralph Droms (for Don Provan) asked if there was any final discussion about the NDS options (draft-provan-dhcp-options-dir-serv-00.txt). Absent any discussion, the option was recommended for Proposed Standard status. 

Mike Carney described changes in the POSIX timezone option (dhc-timezone), made in response to comments from discussion at a previous Working Group meeting. The Working Group approved submission of the POSIX timezone option for Proposed Standard status.

II. DHCPv6 

The DHCPv6 spec and extensions docs (dhc-dhcpv6, dhc-v6exts) had been posted to the Working Group mailing list for Working Group last call prior to the Working Group meeting. A minor problem with the pad extension was discussed. The Working Group also suggested that there are editorial corrections that must be made prior to submission to IETF last call. Jeff Schiller raised a question about security and key management - in an environment with potentially many keys, how does the DHCP client know which key to use? The authors will revise the spec and extensions docs to address this issue.

Pratik Gupta proposed a domain search option. The Working Group pointed out potential confusion between option 15 (domain name) and the domain search option and suggested that text be included to avoid potential confusion. The Working Group requested a draft be written for the proposed domain search option.

Pratik Gupta then opened what turned out to be a wide-ranging discussion on the development of a DHCP MIB. Issues in the discussion included:

&middot; Previous work (CMU, et al.)

&middot; Scope of the MIB

&middot; Monitor only

&middot; Monitor and some control

&middot; Complete configurability

&middot; Notifications 

&middot; Low water mark on free addresses per subnet

·   Unauthorized address use detected

&middot; Failed to give out address because pool exhausted

&middot; Failed to give out address because of authorization failure

&middot; Failed DNS update

&middot; Should MIB include per-client binding for all clients (yes)

&middot; Should relay agents have section in MIB or a separate MIB?

Stuart Kwan discussed a proposal for an option to supply a URL for a proxy configuration file (kwan-proxy-client-conf-00.txt). There was not a Working Group consensus to either move forward or reject. Several objections were raised:

&middot; Vendor-specificity,

&middot; Requires new mode of DHCP operation to return application-specific information

&middot; Should this be a SVRLOC function? 

&middot; Clarification for mixed-media subnets

Ralph Droms (for Sam Martel and Walt Wimer) discussed a clarification for the use of DHCP and BOOTP over mixed-media subnets (martel-bootp-mixedlinklayers-00.txt). The draft had not been widely read; Working Group consensus was to publish as separate clarification or to integrate the material into the next revision of the DHCP spec.

Takeshi Nikida initiated a preliminary discussion on dynamic subnet allocation (dhc-dyn-subnet-conf). The Working Group expressed interest and suggested continued development.

Munil Shah discussed options and modifications to DHCP for support of multicast addresses (dhc-mdhcp, dhc-multopt). Although there is some sentiment within the Working Group that this is an orthogonal problem and a separate protocol might be more appropriate, the Working Group consensus was to suggest continued development. 

Kester Fong initiated a preliminary discussion on dial-up clients and DHCP. The primary issue is handing out multiple addresses to a dial-up subnet. Possible solutions include a DHCP proxy, agent options, or implementing a DHCP server in the dial-up server.

Mike Carney gave a quick review of the results of DHCP testing at the latest Connectathon. He reported that there were no major issues in the protocol specification and that vendors are glad to see that the DHCP spec and options have been issued as Draft Standard RFCs. Outstanding issues in DHCP identified at Connectathon include multiple subnets on a wire, authentication and a protocol validation suite.

Bob Cole (dhc-interserver) and Kim Kinnear (dhc-interserver-alt) led a discussion on their two (somewhat complementary) drafts. There was much discussion about what the inter-server protocol should do and how it should do it. Bob and Kim will get together and try to merge ideas into unified draft.

Olafur Gudmundsson (dhc-security-arch-00.txt) led a spirited discussion on DHCP security. The new security architecture ID was discussed, which addresses fundamental problems with earlier authentication draft (dhc-authentication-03.txt). Concern was expressed that the new architecture would be too expensive computationally to scale well. The Working Group consensus was to continue the discussion on the mailing list.

Addendum: The "Alt" Draft (draft-ietf-dhc-interserver-alt-00.txt)

Kim Kinnear, American Internet Corp., kinnear@american.com

Key Features/Issues:

&middot; Use of "lazy" update removes requirement for inter-server messages between DHCPREQUEST/SELECTING and DHCPACK.

&middot; Servers will continue to service client requests even in the event of network partition. If a client can talk to *any* DHCP server -- even if "its" DHCP server is gone -- it can continue to use its address and will experience *no* interruption of service. 

&middot; Administrators can add/remove server from the group at will. Identification and removal of failed server is responsibility of administrator.

Failure Scenario

_________

| bridge |

-----------------------------------------------------

| | | |

| | | |

| | | |

+------+ | | +------+

|server| | | |server|

| A | | | | B |

+------+ | | +------+

| |

| |

+------+ | +------+

|client| | |client|

| X | | | Y |

+------+ | +------+

|

partition

boundary

Suppose that client Y receives a lease from server A. Then the bridge fails, partitioning the network. Due to the "lazy" update the DHCPACK made it to client Y prior to the partition of the network, but the "PUSH" operation from server A to server B did not complete.

Client Y will attempt to renew several times, and fail since it can't talk to server A. Eventually, client Y will broadcast a rebinding which server B will receive. Since server B knows nothing about client Y, it will ask the other servers in the group (in this case server A) about client Y. When it fails to get an answer, server B will renew client Y's lease on its IP address.

This works because an IP address cannot change the client to which it is bound without the entire server group's awareness. (It *can* become bound for the first time to a client without full knowledge -- it just cannot *change* to be bound to a different client without full knowledge by all servers).

During the partition event, client X can still DISCOVER and receive an address from server A.

Why have configuration messages? Don't we want the administrator to configure the group? YES! .In order to provide a long-term reliable DHCP service, we need to give the administrator the tools necessary to administer the group.

Functions required:

Add a server to a group (or single group-capable server) "already in progress."

Remove a server from a group (either operational or failed).

Servers verify basic configuration information. (Should we verify not just subnets, but actual addresses in subnets?)

Could SCSP be used to support the general "semantics" of the ALT draft? Well ... let's try to map ALT operations into SCSP operations.

ALT Operations SCSP Operations

-------------- ---------------

Address Information Messages:

POLL & COMPLETE POLL Client State Update Solicit (CSUS)

PUSH Client State Update (CSU)

DUMP CSUS

TRANSFER ?

Configuration Messages:

Determine the available groups ?

GROUP JOIN ?

GROUP LEAVE ? 

ANSWER: It is certainly worth a try! 

Slidest

1. DHCP Interserver Protocol

2. DHCP Server Selection Option  (postscript)

3. DHCP Server Identification Option (postscript))

4. DHCP User Classing (postscript)
 

Attendees List