The Wayback Machine - https://web.archive.org/web/20160103054603/http://www.isoc.org/inet95/proceedings/PAPER/127/abst.html
[Help] Last update at http://inet.nttam.com : Mon Aug 7 21:40:03 1995

Abstract -- Problems and Solutions of Dynamic Host Configuration Protocol (DHCP) Network and Application Engineering Track
N2: Routing and Addressing

[Previous] [Table [Next]
[Paper [Paper

Problems and Solutions of Dynamic Host Configuration Protocol (DHCP)

Tominaga, Akihiro ( tomy@sfc.wide.ad.jp)
Nakamura, Osamu ( osamu@sfc.wide.ad.jp)
Teraoka, Fumio ( tera@csl.sony.co.jp)
Murai, Jun ( jun@sfc.wide.ad.jp)

Abstract

1. Introduction

Dynamic Host Configuration Protocol (DHCP)[RFC1541] is a client-server type protocol for dynamic IP address assignment and network parameters notification. We implemented DHCP from scratch and started test operation in March 1994 in the WIDE project, a research project in Japan. Although it is very convenient to use DHCP in a mobile computing environment, some problems of DHCP were found through the test operation. Some of them can be solved by modifying the specification of DHCP. However, it is required to develop a new protocol to solve others. This paper makes problems of DHCP clear, proposes their solutions, and discusses requirements for the new host configuration protocol.

2. DHCP Implementation in the WIDE Project.

Our goals of DHCP implementation are as follows:

A. Major operating systems should be supported.
B. Implementation should be independent of operating systems.
C. The source code should be distributed freely.
Our implementation includes all the modules of DHCP, ie., the server, the client, and the relay-agent. These modules are implemented as application processes with Berkeley Packet Filter in BSD UNIX as well as Network Interface Tap in SunOS. At the end of 1994, our implementation is running on BSD/386, NEWS-OS, SunOS, and FreeBSD. We plan to distribute our source code freely.

3. Problems and Solutions

The test operation of DHCP found some important problems on complexity, fault tolerance, scalability, and reliability as follows:

A. The state transition in the client is too complex.
B. The client cannot continue to use the assigned address when the server fails.
C. The server cannot control the client.
D. Low scalability.
E. There is no ack for DHCPRELEASE.
Problem A means that the protocol is heavy. This makes it hard to implement the client in an operating system kernel or on a single task operating system. Especially, the state transition becomes tremendously complex if the client simultaneously verifies and extends the address lease time. In short, algorithm about retransmission in the specification restricts the timing of verification. Thus, it is necessary to make the algorithms independent of implementation to solve this problem. Other solution is that the server periodically asks the client for lease extension. The client sleeps till an inquiry comes, or verifies at any moment. A disadvantage of this solution is that the processing load of the server increases. In addition, it requires changes of address management strategy of DHCP. Therefore, it is more desirable to develop a new protocol than to change the specification of DHCP.

Problem B means that there is no fault-tolerance with DHCP server. In DHCP, the client explicitly sends a request for lease extension. Therefore if the server or communication path between the server and the client fails, the client cannot extend its lease and must suspend the use of the IP address. To solve this problem, distributed management with multiple servers is considered in the DHC-WG of IETF. However, since DHCP servers update their databases frequently, it is very hard to maintain the consistency among these databases. Currently, there is still no prospect to achieve this mechanism.

Essentially, it is very difficult to solve this problem as long as the server strictly manages address assignment. It is more efficient to change the protocol to make the client work autonomously. Like the solution for Problem A, it is necessary to develop a new protocol. Problem C is a big disadvantage. For example, the server can neither recall assigned addresses nor notify information changes. It is necessary to add a new message type to solve this problem. Problem D; Suppose that many clients begin boot all at once, such as after power failure. The current DHCP have a little consideration, but it is not enough to support hundreds clients. The mechanism is required to send many DHCPOFFER, DHCPACK or DHCPNAK together. The last problem E is trivial. DHCP does not guarantee reliable address release. It affects expandability of DHCP. It can be solved by adding a new message type.

4. Summary

In conclusion, the following first three problems can be solved by extending the protocol of DHCP. This paper will describe some improvements on DHCP including actual message format. On the other hand, the following last two problems need to define an entirely new protocol. This paper will also discuss the requirements for the new protocol.

a. There is no message to control the client by the server.
b. There is few consideration about scalability.
c. DHCPRELEASE doesn't have corresponding acknowledgment.
d. The complexity of state transition of the client.
e. The weakness for the server failure.

References

Droms, R.: Dynamic Host Configuration Protocol, RFC1541, October 1993.
Droms, R.: Dynamic Host Configuration Protocol, draft-ietf-dhc-dhcp-00.txt, November 1994.
Wimer, W.: Clarifications and Extensions for the Bootstrap Protocol, RFC1542, October 1993.
Alexander, S. and Droms, R.: DHCP Options and BOOTP Vendor Extensions, RFC1533, October 1993.
Droms, R.: Interoperation Between DHCP and BOOTP, RFC1534, October 1993.