Anurag Narula, narula@sgi.com, Xtn:3-1136
Note: The terms "DHCP client", "Proclaim Client", or simply the "client" are interchangable.
The Dynamic Host Configuration Protocol (DHCP) is an innovative enhancement to TCP/IP. When plain TCP/IP is used on large numbers of desktops, administrative problems arise, most notably the assigning and tracking of IP addresses among individual computers. DHCP is the result of the Internet Engineering Task Force's efforts to provide a way to assign IP network addresses and provide other TCP/IP stack parameters dynamically. DHCP relieves the network administrator from having to assign an IP address to each participating computer by hand. DHCP also includes an address reservation scheme, so unused IP addresses can be reassigned automatically, and DHCP can be used to hand out local network parameters such as subnet mask and default router addresses. The result is a plug-and-play TCP/IP for the desktop. Several vendors, including Microsoft, Sun, HP, IBM, DG, FTP Software and Competitive Automation, are releasing DHCP-compliant TCP/IP implementations.
The DHCP software consists of the server and the client portions. The IRIXpro 1.0 software package released in April 95 provides the SGI customers with the first released version of the DHCP compliant software. Currently the server portion of the DHCP software needs a netls license, but it will probably be given away with the "university pack" in the future.
To make DHCP really usable the client portion of the software needs to be bundled in with a all platform release of IRIX and be enabled by default. This proposal addresses the various concerns raised during my discussions with some of the engineering staff regarding the possible impact on performance, and the addition of daemon process caused as a result of enabling the DHCP client software in banyan by default.
The cliet will be invoked by the /etc/init.d/run-proclaim script and will be run out of the rc2.d start up sequence. The running of the client at startup will be determined by the chkconfig option autoconfig_ipaddress which be shipped on by default.
If the client system is able to get an address lease from a server on the network, the proclaim daemon will remain active on the client system, but will spend almost all the time sleeping and will only wake up when 1) It is time to renew the address lease (typically at 0.5*total lease time), 2) If the renew had failed it will try to rebind the lease from any available server (usually at 0.875*total lease time), and 3) On receiving a user generated request signal. In the case the client is unable to get an address lease from a server due to any reason (no server, server down, no available addresses....) the daemon will exit.
If the user sends a terminate lease signal (by running /etc/init.d/run-proclaim surrender) the client daemon will shutdown all networking and exit.
If the client lease was obtained through a DHCP server and all attempts to renew and rebind the lease were unsuccessful, the client daemon will shutdown all networking at the termination of the lease and exit.
The addition of the proclaim client invocation to the startup (bootup) sequence will add a maximum potential delay of 10 seconds to the system bootup time, but will be automatically disabled after 2 unsuccessful attempts at finding a server. So in the absence of a server the system will only have this potential delay the first 2 times the system is booted up. Ofcourse the client invocation can always be disabled or enabled manually using the chkconfig autoconfig_ipaddress option.
The various scenarios pertaining to the client system state and the impact of automatic enabling of the DHCP client software are discussed below.
The system address is 192.0.2.1. During the bootup sequence the DHCP client broadcasts a request soliciting an IP address, hostname, netmask, nis domain name, and an IP address lease duration from a DHCP server on the same subnet.
The system accepts the new IP address and other configuration information from the DHCP server and is up and running on the network. The client daemon saves the lease information on disk and sets the appropriate alarm for the lease renewal and goes to sleep.
The client times out after 6 seconds and exits, the system continues through the bootup sequence normally. If it is the 2nd time of this unsuccessful attempt, the client disables the autoconfig_ipaddress chkconfig option and exits.
During the bootup sequence, the client sends a brodcast message requesting a server to validate its address mapping.
The systems comes up on the network with the same address binding as before.
This is the same case as when a client is requsting an IP address that is not valid on its subnet, this case is discussed in section 1.3.
The client times out after 5 seconds and exits, the system continues through the bootup sequence normally. If it is the 2nd time of this unsuccessful attempt, the client disables the autoconfig_ipaddress chkconfig option and then exits.
During the bootup sequence, the client sends a brodcast message requesting a server to validate its address mapping.
The client goes to the initialization state and starts the process of getting a new IP address and configuration parameters as if it were a brand new out of the box system (described in section 1.1.1).
The client times out after 5 seconds and exits, the system continues through the bootup sequence normally. If it is the 2nd time of this unsuccessful attempt, the client disables the autoconfig_ipaddress chkconfig option and then exits. Note that in this case the client is now unable to communicate with anyone as its address is incorrect for that subnet.
[06/22/95] Design Complete
[06/29/95] Coding Complete
[06/30/95] Integration Complete
[07/10/95] System Test Complete
[mm/dd/yy] Alpha Test Cycle
[mm/dd/yy] Early Customer Access Cycle
[mm/dd/yy] Beta Test Cycle
[mm/dd/yy] Manufacturing
[mm/dd/yy] Release
[mm/dd/yy] First Customer Ship