The DHCP Client

The DHCP protocol has two functions with regard to the client. It delivers sufficient information to clients for them to establish an endpoint for network communications, and it supplies other parameters needed by system- and application-level software.

Delivering Client Information

To perform the first function, the DHCP protocol supplies an IP address valid for the network attached to the client's hardware interface. The right to use this IP address is given to the client for a finite period of time, called a lease. This differs from the traditional static configuration. If the client wants to use the IP address for a period of time longer than the original lease, it must periodically negotiate a lease extension with the server through DHCP. When the client no longer needs the IP address, the user of the machine can relinquish its lease, returning it to the pool of available IP addresses. Otherwise, the IP address is reclaimed automatically when its lease expires.

The implementation of the client side of the DHCP protocol on Solaris must meet several criteria. Bootstrapping a Sun workstation is a complex process because of the number and diversity of services that must be configured and invoked. Any DHCP solution must co-exist with other methods already in use, particularly the Reverse Address Resolution Protocol (RARP) and static configuration. It must know that the superuser can change the address of a network interface after the workstation has booted. It must be able to configure multiple interfaces. And it must respond to human control and be able to report on the status and provide the statistics of the protocol.

The Solaris 2 DHCP client meets these criteria by implementing several features. Since leases must be renewed days or weeks after the initial boot, an agent responsible for DHCP on the client must run as a daemon. This daemon, the DHCP agent or dhcpagent (see dhcpagent(1M)) is responsible for all the interactions of the protocol. It sends and receives all the DHCP protocol packets when talking to the server. The daemon:

• Constructs and sends packets

• Listens for responses from servers

• Caches the configuration information received

• Releases or renews leases

• Configures the interfaces with sufficient information to enable communications with the network through the interface

This is where the responsibilities of the agent end. The daemon knows nothing of any higher-level services that the client might be running.

When the agent starts, it assumes nothing about which interfaces are to be configured by DHCP. It waits for instructions from some other entity. These instructions are passed to the agent by a control protocol, which also returns status and other information from the agent to the controller. The controller allows the user to control the behavior of the agent, and implements this control through new features of the ifconfig(1M) command.

The ifconfig command has new command line options specific to DHCP, which start or terminate DHCP on an interface. After DHCP is started on an interface, the agent sends packets to and receives them from a server as the protocol dictates.

In the simplest example, the interface is successfully configured by DHCP. The agent notes the duration of the lease, informs ifconfig that the interface was configured, writes the configuration it received to disk, and goes back to sleep.

At some predetermined future time, usually 50 percent into the lease's lifetime, the agent reawakens and negotiates an extension to the lease. This renegotiation can occur an unlimited number of times while the workstation is running. Eventually, the system is halted. At that time, ifconfig can tell the agent to relinquish the lease. If the lease is relinquished, the configuration information stored on the disk is removed, since it is no longer valid.

The agent can keep track of leases on many different interfaces simultaneously. There is no requirement that they all be renewed at the same time.

The example above is the simplest one, but circumstances might be more complicated. The agent might not receive any responses to its protocol messages. In that case, the agent can use a configuration previously stored on disk, as long as the lease associated with the configuration has not expired. If no valid configuration is found, the agent can continue to retry DHCP using a predefined retransmission schedule, or it can fail to configure the interface. What it does depends on whether the interface was designated as a primary interface. If it was designated as a primary interface, the agent continues to retry DHCP. If it was not designated as a primary interface, the agent fails the ifconfig command.

In addition, the agent must take into account that human intervention might have occurred. If the agent awakens to discover that the IP address and interface status no longer conform to the DHCP configuration received, then the agent drops the interface from its active list. No further DHCP operations will occur on it until the agent is again asked to acquire a lease for the interface.

Supplying Additional Information

To perform its second function, delivering application and system-level information, the Solaris DHCP client uses another program, dhcpinfo(1). Since the agent does not know about these services, any configuration information it receives via the DHCP protocol is stored, waiting to be retrieved by dhcpinfo.

The dhcpinfo command takes a command line argument with a specified parameter, interrogates the agent as to the value of that parameter, and echoes the result to its standard output as a (human readable) text string. However, the chief consumer of the dhcpinfo answers is not the user, but the Solaris 2 startup scripts, since the output lends itself easily to shell command substitution and output redirection.

Data supplied by DHCP can be host-wide or interface-specific. On a client with a single DHCP-configurable interface, this distinction is meaningless. But on a host with many interfaces, questions of interpretation arise regarding dhcpinfo parameters. For example, the agent could configure two interfaces and find that the NIS+ domain name returned for the two differs. This situation is resolved by dividing interfaces into two categories: the primary interface and secondary interfaces.

The primary interface is the preferred one for a host-wide configuration. When dhcpinfo is asked for a value, it consults the primary interface. It does the same in the case of interface-specific data. The values returned are those that were received on the primary interface. For example, if dhcpinfo is asked for the IP address, it echoes the IP address of the primary interface to standard output. An interface is designated as primary by command line arguments to ifconfig.

The dhcpinfo command allows other command line options to override this default behavior. One of these options allows an interface name to be explicitly specified. In that case, the values returned are those delivered by DHCP for that interface.

Because much of the host-wide data is critically important to successful booting of a Solaris 2 client, the designation of an interface as primary implies that the system cannot boot unless the agent can configure that interface. The ifconfig command is instructed by command line arguments to wait indefinitely until dhcpagent has finished configuring the primary interface.