test

TCP/IP and Data Communications Administration Guide

Chapter 14 Understanding DHCP

This chapter introduces the Dynamic Host Configuration Protocol (DHCP) and describes both the client and server sides of the protocol. It discusses Bootstrap Protocol (BOOTP) relay agents, which can be used in the operation of DHCP.

What is DHCP?

DHCP provides a host with an Internet Protocol (IP) address and other Internet configuration parameters without any need for preconfiguration by the user. This new protocol improves on the traditional Internet architecture, where the system administrator must assign or change each IP address individually. The manual process is expensive, difficult, error-prone and time-consuming.

DHCP reduces the cost of managing networks by eliminating the need for the administrator to assign or change IP addresses again and again. Dynamic IP addresses are chosen from a pool of unused IP addresses, and are automatically assigned to a host for temporary or permanent use. DHCP also reclaims that IP address for use by other clients when it is no longer needed or when the time period for its use is up.

The packet formats for DHCP and BOOTP are the same, although BOOTP packets are fixed length and DHCP packets are variable length. The DHCP packet length is negotiated between the client and the server.

The Dynamic Host Configuration working group of the Internet Engineering Task Force (IETF) has been working for approximately five years on the problems presented by the current IP address assignment architecture. The IETF is in the process of standardizing DHCP. It currently has the status of several Requests For Comment (RFCs), including RFCs 1542, 2131, and 2132.

The Internet has grown so rapidly that users are running out of network addresses to support it. In response to this problem, Classless Inter-Domain Routing (CIDR) was developed. IP addresses had been separated into class A, B, and C for large, medium, and small networks. As the class B IP addresses were depleted, the CIDR design came into use. CIDR was based on the idea that an organization should get the exact number of class C IP addresses it needs, rather than be assigned one class B network, consisting of 65,536 addresses.

The class C network numbers allocated following the CIDR strategy are not random. They are contiguous and share the same prefixes. This helps alleviate many of the problems caused by manipulating very large routing tables.

With the CIDR strategy, blocks of IP addresses are allocated to individual ISPs, not to individual requestors or companies, as was previously the case. So it becomes important to renumber easily, in order to change ISPs easily. DHCP makes it easy to renumber networks, and therefore easier to change ISPs.

DHCP is a technology that enables several useful features, including:

DHCP can also exploit existing BOOTP relay functionality since DHCP is based on the BOOTP. This permits network administrators to configure their routers to forward BOOTP/DHCP traffic to remote BOOTP/DHCP servers. Therefore, network parameter servers are no longer needed on every network segment, as was true of the in,rarpd (see in.rarpd(1M)) and bootparams configuration services.

A network administrator can use the command to quickly and easily configure DHCP and BOOTP services on a Solaris 2 server. The command bootstraps the DHCP service and configures local and remote networks. Local networks are those to which the server is directly connected. Remote networks are those to which the server is not directly connected, but are accessed through BOOTP relay agents.

Serving clients on remote networks requires the configuration of a BOOTP relay agent on the client's network. BOOTP relay agent functionality is present in many popular routers and switches. If your router does not support this feature, you can run the in.dhcpd daemon (see in.dhcpd(1M)) in relay agent mode on any Solaris 2 machine on the client's network capable of running in.dhcpd. This is true for machines running Solaris 2.6 and later releases. Figure 14-1 shows an overview of DHCP and BOOTP.

Figure 14-1 DHCP Architectural Diagram

Graphic

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:

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.

DHCP Server

The DHCP server manages the IP address space of networks directly connected to that server. To extend this environment into other networks, DHCP servers or BOOTP relay agents must be set up on those networks.

A DHCP server can act as a primary or a secondary server. To be a primary server, it must have a range of IP addresses for which it is responsible.

Note -

The term primary is used differently for the client and the server.

When a DHCP server is added to a network that already has a primary DHCP server, the new server can be configured to provide primary and secondary service, or secondary service only. If the server is configured for both services, both servers can perform the duties of a primary server, (they can give out IP addresses) as long as each is primarily responsible for a different IP range. Each server can act as a secondary server for the other, by confirming existing configurations supplied by a primary server when the primary server is unable to respond to requests for confirmation. Every primary server automatically acts as a secondary server.

A DHCP server's range of IP addresses is specified during the installation and configuration of the software on the server. As a primary DHCP server, the server can give out an IP address to a client requesting a new configuration from the range of IP addresses for which it is responsible. When a client asks for confirmation of its existing configuration, the server responsible for that client's IP address confirms the configuration. Acting as a secondary server, it can confirm configurations that were supplied by another DHCP server on the network.

To provide secondary service, the DHCP server confirms configurations that were supplied by another DHCP server on the network. It does this when the primary server responsible for those IP addresses cannot respond. After a waiting period, the secondary server responds in its place.

DHCP servers can be configured as secondary only. If you decide you want to configure a DHCP server as a secondary server only, you can do this through the dhcpconfig program, by choosing to configure the server without a range of IP addresses that it can give out to clients requesting a new configuration. In this configuration, the DHCP servers should be using NIS+ for their data storage.

DHCP service is enabled and configured on the machine on which it is run with the dhcpconfig utility. This utility allows you to set startup options, configure the DHCP service database type and location, and initialize the dhcptab and dhcp_network tables for any locally attached or remote networks.

When dhcpconfig is invoked, it presents a menu offering the option of configuring the DHCP service, configuring a BOOTP relay agent, removing the DHCP configuration or relay service configuration, or exiting. When the administrator selects one of the menu options, he or she is presented with a series of questions to collect the required information. Then dhcpconfig performs the appropriate steps to turn on the selected functions.

Multiple DHCP servers on the same network operate much more efficiently if they share DHCP databases through NIS+ or NFS. Sharing allows DHCP servers to communicate through a common datastore, increasing redundancy and balancing load among cooperating servers.

When a new DHCP client is added to the network, the client broadcasts a message intended to locate all available DHCP and/or BOOTP servers within reach. Any DHCP server that receives the message first checks to see if any IP addresses are available for assignment. If they are, the server verifies that a potential IP address is not already in use. If it is not, the server offers the IP address and other configuration information to the client. If the IP address is in use, the server marks this IP address as unusable, notifies the network administrator of its status, and selects another IP address.

The client selects an IP address offered to it based on its own criteria, and broadcasts a message that identifies its selection.

Server Databases

The DHCP/BOOTP server uses two types of databases: the dhcptab database and the dhcp_network databases (see dhcp_network(4).

The dhcptab database contains macros defined using a termcap-like syntax. This syntax permits network administrators to define groups of DHCP configuration parameters to be returned to clients. There are currently 77 predefined parameters.

A DHCP/BOOTP server returns hostname, network broadcast address, network subnet mask, or IP maximum transfer unit (MTU), if this information is requested by a client attached to the same network as the server. This information does not have to be explicitly configured in the dhcptab. The dhtadm command manages the dhcptab service configuration table.

If there are two servers sharing a distributed dhcptab table, the administrator can configure the DHCP parameters in the table so the servers back each other up, provided that they are in the same NIS+ domain. However, each should be primarily responsible for a different range of IP addresses. Each network might require a BOOTP relay agent as well, so its clients can reach the server on the other network.

The dhcp_network databases contain client identifier-to-IP address mappings. These databases are named after the network they support. There is one dhcp_network database for each network that offers DHCP/BOOTP services. The dhcp_network databases are located dynamically by the server and consulted during runtime. A client request received from a network for which no dhcp_network database exists is ignored.

The dhcp_network database maps a DHCP client's client identifier to an IP address and the configuration parameter associated with that IP address. This database is located by the DHCP server at runtime by generating a dhcp_network database name by using the IP network address and subnet mask for the network where the DHCP request originated. For example, a dhcp_network database that supports the 10.0.0.0 network would be called 10_0_0_0. The dhcp_network databases can exist as NIS+ tables or ASCII files. Use the pntadm command to manage the dhcp_network databases.

The in.dhcpd daemon has two run modes, DHCP server (with optional BOOTP compatibility mode) and BOOTP relay agent mode (see in.dhcpd(1M).

BOOTP Relay Agents

Multiple networks, and the use of netmasks to identify them, complicate the functioning of TCP/IP-based networks. For instance, broadcasting using IP cannot take place through the gateways that link networks. So clients on one network cannot broadcast DHCP or BOOTP requests to servers on other networks. A BOOTP relay agent must direct the initial requests through the gateway to the server, then return the replies from the server to the clients.

If your router doesn't have a built-in BOOTP relay agent, and you want clients in other networks to have the advantage of the services installed on the DHCP server, you can install BOOTP relay agents on those networks. This allows clients to access DHCP servers from a network that is not running a DHCP server.

The in.dhcpd daemon can be run as a BOOTP relay agent. If you specify BOOTP relay agent mode, the option argument specifies a comma-separated list of IP addresses or the hostnames of DHCP or BOOTP servers to which the relay agent must forward BOOTP requests. When the daemon is started in this mode, any DHCP databases are ignored, and the daemon acts as a BOOTP relay agent.

A BOOTP relay agent listens to UDP port 68, and forwards BOOTP request packets received on this port to the destinations specified on the command line. The relay agent can run on any machine that has knowledge of local routers, so it does not have to be an Internet gateway machine.

The -r IPaddr | hostname ... option enables the BOOTP relay agent. The proper entries need to be made to the netmasks database so that the DHCP server served by the BOOTP relay agents can identify the subnet mask of the foreign BOOTP/DHCP client's network.

After you install the BOOTP relay agent, entries must be added to the distributed DHCP databases so the DHCP servers can service clients sending requests through the BOOTP relay agent.

The macro option (-M) for PNTADM command is a mechanism that permits the network administrator to select configuration parameters to be returned to clients using a particular IP address. It can also be used to deliver a macro with server-specific information by including this macro definition in all dhcp_network database entries owned by a specific server.

Leases

The DHCP/BOOTP server calculates a client's IP address lease using information contained in the dhcptab and dhcp_network databases. The server consults the LeaseTim and LeaseNeg symbols in the dhcptab database, and the Flags and Lease fields of the chosen dhcp_network database record.

The server first examines the Flags field for the identified dhcp_network record. If the PERMANENT or BOOTP flag is on, then the client's lease is considered permanent.

If the PERMANENT flag is not on, then the server checks to see if the client's lease, as represented by the Lease field in the dhcp_network record, has expired. If it has not, the server checks to see if the client has requested a new lease. If the LeaseNeg symbol has not been included in the client's dhcptab parameters, then the client's requested lease extension is ignored, and the lease is set to be the time remaining as shown in the Lease field.

If the LeaseNeg symbol has been included, the server extends the client's lease to the value it requested, provided this requested lease is less than or equal to the current time plus the value of the client's LeaseTim dhcptab parameter. If the client's requested lease is greater than policy allows (the policy is the value of LeaseTim), then the client is given a lease equal to the current time, plus the value of LeaseTim. If LeaseTim is not set, then the default LeaseTim value is one hour.