Chapter 1 Overview of DHCP

This chapter introduces the Dynamic Host Configuration Protocol (DHCP), explains the concepts underlying the protocol, and describes the advantages of using it in your network.

This chapter contains the following information:

• About the DHCP Protocol

• Advantages of Using Solaris DHCP

• How DHCP Works

• Solaris DHCP Server

• Solaris DHCP Client

About the DHCP Protocol

The DHCP protocol enables host systems in a TCP/IP network to be configured automatically for the network as they boot. DHCP uses a client/server mechanism. Servers store and manage configuration information for clients, and provide that information upon a client's request. The information includes the client's IP address and information about network services available to the client.

DHCP evolved from an earlier protocol, BOOTP, which was designed for booting over a TCP/IP network. DHCP uses the same format as BOOTP for messages between client and sever, but includes more information in the messages. The additional information is the network configuration data for the client.

A primary benefit of DHCP is its ability to manage IP address assignments through leasing, which allows IP addresses to be reclaimed when not in use and reassigned to other clients. This enables a site to use a smaller pool of IP address than would be needed if all clients were assigned a permanent address.

Advantages of Using Solaris DHCP

DHCP relieves the system or network administrator of some of the time-consuming tasks involved in setting up a TCP/IP network and the daily management of that network. Note that Solaris DHCP works only with IPv4.

Solaris DHCP offers the following advantages:

• IP address management – A primary advantage of DHCP is easier management of IP addresses. In a network without DHCP, an administrator must manually assign IP addresses, being careful to assign unique IP addresses to each client and configure each client individually. If a client moves to a different network, the administrator must make manual modifications for that client. When DHCP is enabled, the DHCP server manages and assigns IP addresses without administrator intervention. Clients can move to other subnets without manual reconfiguration because they obtain, from a DHCP server, new client information appropriate for the new network.

• Centralized network client configuration – A network administrator can create a tailored configuration for certain clients, or certain types of clients, and keep the information in one place, the DHCP data store. The administrator does not need to log in to a client to change its configuration. The administrator can make changes for multiple clients just by changing the information in the data store.

• Support of BOOTP clients – Both BOOTP servers and DHCP servers listen and respond to broadcasts from clients. The DHCP server can respond to requests from BOOTP clients as well as DHCP clients. BOOTP clients receive an IP address and the information needed to boot from a server.

• Support of local and remote clients – BOOTP provides for the relaying of messages from one network to another. DHCP takes advantage of the BOOTP relay feature in several ways. Most network routers can be configured to act as BOOTP relay agents to pass BOOTP requests to a server that is not on the client's network. DHCP requests can be relayed in the same manner because, to the router, they are indistinguishable from BOOTP requests. The Solaris DHCP server can also be configured to behave as a BOOTP relay agent, if a router that supports BOOTP relay is not available.

• Network booting – Clients can use DHCP to obtain the information needed to boot from a server on the network, instead of using RARP (Reverse Address Resolution Protocol) and bootparams. The DHCP server can give a client all the information it needs to function, including IP address, boot server, and network configuration information. Because DHCP network boot requests can be relayed across subnets, you can deploy fewer boot servers in your network when you use DHCP network booting. RARP booting requires that each subnet has a boot server.

• Large network support - Networks with millions of DHCP clients can use Solaris DHCP. The DHCP server uses multithreading to process many client requests simultaneously and supports data stores optimized to handle large amounts of data. Data store access is handled by separate processing modules, and sites can add support for any database they want to use for their DHCP data.

How DHCP Works

The DHCP server must first be installed and configured by a system administrator. During configuration, the administrator enters information about the network that clients will need to operate on the network. After this information is in place, clients are able to request and receive network information.

The sequence of events for DHCP service is shown in the following diagram. The numbers in circles correlate to the numbered items in the description following the diagram.

Figure 1–1 Sequence of Events for DHCP Service

LEGEND:

1. The client discovers a DHCP server by broadcasting a discover message to the limited broadcast address (255.255.255.255) on the local subnet. If a router is present and configured to behave as a BOOTP relay agent, the request is passed to other DHCP servers on different subnets. The client's broadcast includes its unique ID, which in the Solaris DHCP implementation, is derived from the client's Media Access Control (MAC) address. On an Ethernet network, the MAC address is the same as the Ethernet address.

   DHCP servers that receive the discover message can determine the client's network by looking at the following information:

   • Which network interface did the request come in on? This tells the server that the client is either on the network to which the interface is connected, or that the client is using a BOOTP relay agent connected to that network.

   • Does the request include the IP address of a BOOTP relay agent? When a request passes through a relay agent, the relay agent inserts its address in the request header. When the server detects a relay agent address, it knows that the network portion of the address indicates the client's network address because the relay agent must be connected to the client's network.

   • Is the client's network subnetted? The server consults the netmasks table to find the subnet mask used on the network indicated by the relay agent's address or the address of the network interface that received the request. Once the server knows the subnet mask used, it can determine which portion of the network address is the host portion, and then select an IP address appropriate for the client. (See netmasks(4) for information on netmasks.)

2. After they determine the client's network, DHCP servers select an appropriate IP address and verify that the address is not already in use. The DHCP servers then respond to the client by broadcasting an offer message that includes the selected IP address and information about services that can be configured for the client. Each server temporarily reserves the offered IP address until it can determine if the client will use it.

3. The client selects the best offer (based on the number and type of services offered) and broadcasts a request that specifies the IP address of the server that made the best offer. The broadcast ensures that all the responding DHCP servers know the client has chosen a server, and those servers not chosen can cancel the reservations for the IP addresses they had offered.

4. The selected server allocates the IP address for the client, stores the information in the DHCP data store, and sends an acknowledgement (ACK) to the client. The acknowledgement message contains the network configuration parameters for the client. The client uses ping to test the IP address to make sure no other system is using it, then continues booting to join the network.

5. The client monitors the lease time, and when a set period of time has elapsed, the client sends a new message to the chosen server to increase its lease time.

6. The DHCP server that receives the request extends the lease time if it still adheres to the local lease policy set by the administrator. If the server does not respond within 20 seconds, the client broadcasts a request so that one of the other DHCP servers can extend the lease.

7. When the client no longer needs the IP address, it notifies the server that it is releasing the IP address. This can happen during an orderly shutdown and can also be done manually.

Solaris DHCP Server

The Solaris DHCP server runs as a daemon in the Solaris operating environment on a host system. The server has two basic functions:

• Managing IP addresses – The server controls a range of IP addresses, and allocates them to clients, either permanently or for a defined period of time. The DHCP server uses a lease mechanism to determine how long a client can use a nonpermanent address. When the address is no longer in use, it is returned to the pool and can be reassigned. The server maintains information about the binding of IP addresses to clients in its DHCP network tables, ensuring that no address is used by more than one client.

• Providing network configuration for clients – The server assigns an IP address and provides other information for network configuration, such as a hostname, broadcast address, network subnet mask, default gateway, name service, and potentially much more information. The network configuration information is obtained from the server's dhcptab database.

The Solaris DHCP server can also be configured to perform the following additional functions:

• Responding to BOOTP client requests – The server listens for broadcasts from BOOTP clients discovering a BOOTP server and provides them with an IP address and boot parameters. The information must have been configured statically by an administrator. The DHCP server can perform as a BOOTP server and DHCP server simultaneously.

• Relaying requests – The server relays BOOTP and DHCP requests to appropriate servers on other subnets. The server cannot provide DHCP or BOOTP service when configured as a BOOTP relay agent.

• Providing network booting support for DHCP clients – The server can provide DHCP clients with information needed to boot over the network: IP address, boot parameters, and network configuration information.

• Updating DNS tables for clients that supply a host name – For clients that provide a Hostname option and value in their requests for DHCP service, the server can attempt DNS updates on their behalf.

DHCP Server Management

As superuser, you can start, stop, and configure the DHCP server with the DHCP Manager, or with command-line utilities described in DHCP Command-Line Utilities. Generally, the DHCP server is configured to start automatically when the system boots, and stop when the system is shut down. You should not need to start and stop the server manually under normal conditions.

DHCP Data Store

All the data used by the Solaris DHCP server is maintained in a data store, which might be stored as plain text files, NIS+ tables, or binary-format files. While configuring the DHCP service, the administrator chooses the type of data store to be used. The section Choosing the Data Store describes the differences between the data stores. Data stores can be converted from one format to another using DHCP Manager or the dhcpconfig command.

You can also move data from one DHCP server's data store to another with export and import utilities that work with the data stores, even if the servers are using different data store formats. The entire content of a data store, or just some of the data within it, can be exported and imported using DHCP Manager or the dhcpconfig command.

---

Note –

Any database or file format can be used for DHCP data storage if you want to develop your own code module to provide an interface between Solaris DHCP (server and management tools) and the database. Solaris DHCP Service Developer's Guide contains information for doing this.

---

Within the Solaris DHCP data store are two types of tables, the contents of which you can view and manage by using either the DHCP Manager or command-line utilities. The data tables are:

• dhcptab table – Table of configuration information that can be passed to clients.

• DHCP network tables – Tables that contain information about the DHCP and BOOTP clients that reside on the network specified in the table name. For example, the network 134.20.0.0 would have a table whose name includes 134_20_0_0.

The dhcptab Table

The dhcptab table contains all the information that clients can obtain from the DHCP server. The DHCP server scans the dhcptab each time it starts. The file name of the dhcptab varies according to the data store used. For example, the dhcptab created by the NIS+ data store SUNWnisplus is SUNWnisplus1_dhcptab.

The DHCP protocol defines a number of standard items of information that can be passed to clients. These items are referred to as parameters, symbols, or options. Options are defined in the DHCP protocol by numeric codes and text labels, but without values. Some commonly used standard options are shown in the following table.

Table 1–1 Sample DHCP Standard Options

Code	Label	Description
1	Subnet	Subnet mask IP address
3	Router	IP address for router
6	DNSserv	IP address for DNS server
12	Hostname	Text string for client host name
15	DNSdmain	DNS domain name

Some options are automatically assigned values when the administrator provides information during server configuration. The administrator can also explicitly assign values to other options at a later time. Options and their values are passed to the client to provide configuration information. For example, the option/value pair, DNSdmain=Georgia.Peach.COM, sets the client's DNS domain name to Georgia.Peach.COM.

Options can be grouped with other options in containers known as macros, which makes it easier to pass information to a client. Some macros are created automatically during server configuration, and contain options that were assigned values during configuration. Macros can also contain other macros.

The format of the dhcptab table is described in dhcptab(4) man page. In DHCP Manager, all the information shown in the Options and Macros tabs comes from the dhcptab table. See About Options for more information about options, and About Macros for more information about macros.

Note that the dhcptab table should not be edited manually. You should use either the dhtadm command or DHCP Manager to create, delete, or modify options and macros.

DHCP Network Tables

A DHCP network table maps client identifiers to IP addresses and the configuration parameters associated with each address. The format of the network tables is described in the dhcp_network(4) man page. In DHCP Manager, all the information shown in the Addresses tab is acquired from the network tables.

DHCP Manager

DHCP Manager is a graphical tool you can use to perform all management duties associated with DHCP services, and you must be root when you run it. You can use it to manage the server itself as well as the data the server uses. You can use DHCP Manager with the server in the following ways:

• Configure and unconfigure the DHCP server

• Start, stop, and restart the DHCP server

• Disable and enable DHCP service

• Customize server settings

DHCP Manager allows you to manage the IP addresses, network configuration macros, and network configuration options in the following ways:

• Add and delete networks under DHCP management

• View, add, modify, delete, and release IP addresses under DHCP management

• View, add, modify, and delete network configuration macros

• View, add, modify, and delete nonstandard network configuration options

DHCP Manager allows you to manage the DHCP data stores in the following ways:

• Convert data to a new data store format

• Move DHCP data from one DHCP server to another by exporting it from the first server and importing it on the second server

DHCP Manager includes extensive online help for procedures you can perform with the tool.

DHCP Command-Line Utilities

All DHCP management functions can be performed using command-line utilities. You can run them if you are logged in as root, or as a user assigned to the DHCP Management profile. See Setting Up User Access to DHCP Commands.

The following table lists the utilities and describes the purpose of each utility.

Table 1–2 DHCP Command-Line Utilities

Command	Description and Purpose
in.dhcpd	The DHCP service daemon. It provides command-line arguments that allow you to set several runtime options.
dhcpconfig	Used to configure and unconfigure a DHCP server. This utility enables you to perform many of the functions of DHCP Manager from the command line. It is primarily intended for use in scripts for sites that want to automate some configuration functions. dhcpconfig collects information from the server system's network topology files to create useful information for the initial configuration.
dhtadm	Used to add, delete, and modify configuration options and macros for DHCP clients. This utility lets you edit the dhcptab indirectly, which ensures the correct format of the dhcptab. You should not directly edit the dhcptab.
pntadm	Used to manage the DHCP network tables. You can use this utility to add and remove IP addresses and networks under DHCP management, modify the network configuration for specified IP addresses, and display information about IP addresses and networks under DHCP management.

Role-Based Access Control for DHCP Commands

Security for the dhcpconfig, dhtadm, and pntadm commands is determined by role-based access control (RBAC) settings. By default, the commands can be run only by root. If you want to be able to use the commands under another user name, you must assign the user name to the DHCP Management profile as described in Setting Up User Access to DHCP Commands.

DHCP Server Configuration

You configure the DHCP server the first time you run DHCP Manager on the system where you want to run the DHCP server. DHCP Manager server configuration dialogs prompt you for essential information needed to enable and run the DHCP server on one network. Some default values are obtained from existing system files. If you have not configured the system for the network, there will be no default values. DHCP Manager prompts for the following information:

• Role of the server, either DHCP server or BOOTP relay agent

• Data store type (files, binary files, NIS+, or something specific to your site)

• Data store configuration parameters, which vary according to the data store type you selected

• Naming service to use to update host records, if any (/etc/hosts, NIS+, or DNS)

• Length of lease time and whether clients should be able to renew leases

• DNS domain name and IP addresses of DNS servers

• Network address and subnet mask for the first network you want to be configured for DHCP service

• Network type, either LAN or point-to-point

• Router discovery or the IP address of a particular router

• NIS domain name and IP address of NIS servers

• NIS+ domain name and IP address of NIS+ servers

You can also configure the DHCP server using the dhcpconfig command. This utility gathers information from existing system files automatically in order to provide a useful initial configuration. Therefore, you must ensure that the files are correct before running dhcpconfig. See the dhcpconfig(1M) man page for information about the files dhcpconfig uses to obtain information.

IP Address Allocation

The Solaris DHCP server supports the following types of IP address allocation:

• Manual allocation – The server provides a specific IP address chosen by the administrator for a specific DHCP client. The address cannot be reclaimed or assigned to any other client.

• Automatic, or permanent, allocation – The server provides an IP address that has no expiration time, making it permanently associated with the client until the administrator changes the assignment or the client releases the address.

• Dynamic allocation – The server provides an IP address to a requesting client, with a lease for a specific period of time. When the lease expires, the address is taken back by the server and can be assigned to another client. The period of time is determined by the lease time configured for the server.

Network Configuration Information

The administrator determines what information to provide to DHCP clients. When you configure the DHCP server you provide essential information about the network. Later, you can add more information you want to provide to clients.

The DHCP server stores network configuration information in the dhcptab database, in the form of option/value pairs and macros. Options are keywords for network data you want to supply to clients. Values are assigned to options and passed to clients in DHCP messages. For example, the NIS server address is passed by way of an option called NISservs that has a value (a list of IP addresses) assigned by the DHCP server. Macros provide a convenient way to group together any number of options that you want to supply to clients. You can use the DHCP Manager to create macros to group options and assign values to the options. If you prefer a nongraphical tool, you can use dhtadm, the DHCP configuration table management utility, to work with options and macros.

About Options

In Solaris DHCP, an option is a piece of network information to be passed to a client. The DHCP literature also refers to options as symbols or tags. An option is defined by a numeric code and a text label. An option receives a value when it is used in the DHCP service.

The DHCP protocol defines a large number of standard options for commonly specified network data: Subnet, Router, Broadcast, NIS+dom, Hostname, and LeaseTim are a few examples. A complete list of standard options is shown in the dhcp_inittab man page. You cannot modify the standard option keywords in any way, but you can assign values to the options that are relevant to your network when you include the options in macros.

You can create new options for data that is not represented by the standard options. Options you create must be classified in one of three categories:

• Extended – Reserved for options that have become standard DHCP options, but are not yet included in the DHCP server implementation. You might use this if you know of a standard option that you want to use, but do not want to upgrade your DHCP server.

• Site – Reserved for options that are unique to your site. The system administrator creates these options.

• Vendor – Reserved for options that should apply only to clients of a particular class, such as hardware or vendor platform. The Solaris DHCP implementation includes a number of vendor options for Solaris clients. For example, the option SrootIP4 is used to specify the IP address of a server that a client that boots from the network should use for its root file system.

Chapter 4, Administering DHCP includes procedures for creating, modifying, and deleting options.

About Macros

In the Solaris DHCP service, a macro is a collection of network configuration options and the values assigned to them by the system administrator. Macros are created to group options together to be passed to specific clients or types of clients. For example, a macro intended for all clients of a particular subnet might contain option/value pairs for subnet mask, router IP address, broadcast address, NIS+ domain, and lease time.

Macro Processing by the DHCP Server

When the DHCP server processes a macro, it places the network options and values defined in the macro in a DHCP message to a client. The server processes some macros automatically for clients of a particular type.

In order for the server to process a macro automatically, the name of the macro must comply with one of the categories shown in the following table.

Table 1–3 Macro Categories for Automatic Processing

Macro Category	Description
Client class	The macro name matches a class of client, indicated by the client machine type and/or operating system. For example, if a server has a macro named SUNW.Ultra-1, any client whose hardware implementation is SUNW,Ultra-1 automatically receives the values in the SUNW.Ultra-1 macro.
Network address	The macro name matches a DHCP-managed network IP address. For example, if a server has a macro named 125.53.224.0, any client connected to the 125.53.224.0 network automatically receives the values in the 125.53.224.0 macro.
Client ID	The macro name matches some unique identifier for the client, usually derived from an Ethernet or MAC address. For example, if a server has a macro named 08002011DF32, the client with the client ID 08002011DF32 (derived from the Ethernet address 8:0:20:11:DF:32) automatically receives the values in the macro named 08002011DF32.

A macro with a name that does not use one of the categories listed in Table 1–3 can be processed only if one of the following is true:

• Macro is mapped to an IP address.

• Macro is included in another macro that is processed automatically.

• Macro is included in another macro that is mapped to an IP address.

---

Note –

When you configure a server, a macro that is named to match the server's name is created by default. This server macro is not processed automatically for any client because it is not named with one of the name types that cause automatic processing. When you later create IP addresses on the server, the IP addresses are mapped to use the server macro by default.

---

Order of Macro Processing

When a DHCP client requests DHCP services, the DHCP server determines which macros match the client. The server processes the macros, using the macro categories to determine the order of processing, from the more general to the specific. The macros are processed in the following order:

1. Client class macros – the most general category

2. Network address macros – more specific than Client class

3. Macros mapped to IP addresses – more specific than Network address

4. Client ID macros – the most specific category, pertaining to one client

A macro that is included in another macro is processed as part of the containing macro.

If the same option is included in more than one macro, the value set for that option in the macro with the most specific category is used because it is processed last. For example, if a Network address macro contained the lease time option with a value of 24 hours, and a Client ID macro contained the lease time option with a value of 8 hours, the client would receive a lease time of 8 hours.

Solaris DHCP Client

The term “client” is sometimes used to refer to a physical machine that is performing a client role on the network. However, the DHCP client described here is a software entity. The Solaris DHCP client is a daemon (dhcpagent) that runs in the Solaris operating environment on a system that is configured to receive its network configuration from a DHCP server. DHCP clients from other vendors can also use the services of the Solaris DHCP server. However, this section describes only the Solaris DHCP client.

Notice that the description assumes one network interface. The section DHCP Client Systems With Multiple Network Interfaces discusses issues important for hosts that have two or more network interfaces.

DHCP Client Installation

The Solaris DHCP client is installed and enabled on a system during installation of the Solaris operating environment when you specify that you want to use DHCP to configure network interfaces. You do not need to do anything else on the Solaris client to use DHCP.

If you want a system that is already running the Solaris operating environment to use DHCP to obtain network configuration information, see Configuring and Unconfiguring a Solaris DHCP Client.

DHCP Client Startup

The dhcpagent daemon obtains configuration information that is needed by other processes involved in booting the system. For this reason, the system startup scripts start dhcpagent early in the boot process and wait until the network configuration information from the DHCP server arrives.

The presence of the file /etc/dhcp.interface (for example, /etc/dhcp.hme0 on a Sun Enterprise Ultra^TM system) indicates to the startup scripts that DHCP is to be used on the specified interface. Upon finding a dhcp.interface file, the startup scripts start the dhcpagent daemon.

After startup, dhcpagent waits until it receives instructions to configure a network interface. The startup scripts issue the ifconfig interface dhcp start command, which instructs dhcpagent to start DHCP as described in How DHCP Works. If commands are contained within the dhcp.interface file, they are appended to the dhcp start option of ifconfig. See the ifconfig(1M) man page for more information about options used with the dhcp option.

How Solaris DHCP Client Manages Network Configuration Information

After the information packet is obtained from a DHCP server, dhcpagent configures the network interface and brings it up, controlling the interface for the duration of the lease time for the IP address. The dhcpagent daemon maintains the configuration data in an internal table held in memory. The system startup scripts use the dhcpinfo command to extract configuration option values from the dhcpagent daemon's table. The values are used to configure the system and enable it to join the network.

The agent waits passively until a period of time elapses, usually half the lease time, and then requests an extension of the lease from a DHCP server. If the dhcpagent daemon finds that the interface is down or the IP address has changed, it does not control the interface until it is instructed by the ifconfig command to do so. If the dhcpagent daemon finds that the interface is up and the IP address hasn't changed, it sends a request to the server for a lease renewal. If the lease cannot be renewed, the dhcpagent daemon takes down the interface at the end of the lease time.

DHCP Client Management

The Solaris DHCP client does not require management under normal system operation. It automatically starts when the system boots, renegotiates leases, and stops when the system shuts down. You cannot manually start and stop the dhcpagent daemon. However, you can use the ifconfig command as superuser on the client system to affect the client's management of the network interface if necessary.

ifconfig Command Options Used With DHCP Client

The ifconfig command enables you to:

• Start the DHCP client – The command ifconfig interface dhcp start initiates the interaction between the DHCP client and DHCP server to obtain an IP address and a new set of configuration options. This might be useful when you change information that you want a client to use immediately, such as when you add IP addresses or change the subnet mask.

• Request network configuration information only – The command ifconfig interface dhcp inform causes dhcpagent to issue a request for network configuration parameters, with the exception of the IP address. This is useful for situations where the network interface has a valid IP address, but the client system needs updated network options. For example, this might be useful if you do not use DHCP to manage IP addresses, but do use it to configure hosts on the network.

• Request a lease extension – The command ifconfig interface dhcp extend causes dhcpagent to issue a request to renew the lease. This happens automatically, but you might want to use this command if you change the lease time and want clients to use the new lease time immediately rather than waiting for the next attempt at lease renewal.

• Release the IP address – The command ifconfig interface dhcp release causes dhcpagent to relinquish the IP address used by the network interface. This happens automatically when the lease expires. You might want to issue this command if the lease time is long and you need to take down the network interface for an extended period of time or you want to remove the system from the network.

• Drop the IP address – The command ifconfig interface dhcp drop causes dhcpagent to take down the network interface without informing the DHCP server that it is doing so. This enables the client to use the same IP address when it reboots.

• Ping the network interface – The command ifconfig interface dhcp ping lets you test to see if the interface is under the control of DHCP.

• View DHCP configuration status of the network interface – The command ifconfig interface dhcp status displays the current state of the DHCP client. The display indicates the following:

  • If an IP address has been bound to the client

  • Number of requests sent, received, and declined

  • If this is the primary interface

  • Times when the lease was obtained, when it expires, and when attempts to renew it will or did start

  For example:

  # ifconfig hme0 dhcp status Interface State Sent Recv Declined Flags hme0 BOUND 1 1 0 [PRIMARY] (Began, Expires, Renew) = (08/16/2000 15:27, 08/18/2000 13:31, 08/17/2000 15:24)

DHCP Client Parameter File

The file /etc/default/dhcpagent on the client system contains tunable parameters for the dhcpagent daemon. You can use a text editor to change several parameters that affect client operation. The file is well documented so you should refer to the file for more information, as well as referring to the dhcpagent man page.

DHCP Client Shutdown

When the system running the DHCP client shuts down normally, the dhcpagent daemon writes the current configuration information to the file /etc/dhcp/interface.dhc. The lease is dropped rather than released, so the DHCP server does not know that the IP address is not in active use.

If the lease is still valid when the system reboots, the DHCP client sends an abbreviated request to use the same IP address and network configuration information it had used before the system rebooted. If the DHCP server permits this, the client can use the information that it wrote to disk when the system shut down. If the server does not permit the client to use the information, the client initiates the DHCP protocol sequence described previously and obtains new network configuration information.

DHCP Client Systems and Name Services

Solaris systems support the following name services: DNS, NIS, NIS+, and a local file store (/etc/hosts). Each name service requires some configuration before it is usable. The name service switch configuration file (see nsswitch.conf(4)) must also be set up appropriately to indicate the name services to be used.

Before a DHCP client system can use a name service, you must configure the system as a client of the name service.

The following table summarizes issues related to each name service and DHCP, and includes links to documentation that can help you set up clients for each name service.

Table 1–4 Name Service Client Setup Information for DHCP Client Systems

Name Service	Client Setup Notes
NIS	If you are installing the Solaris operating environment on a client system by using Solaris DHCP, you can use a configuration macro that contains the NISservs and NISdmain options to pass the IP addresses of NIS servers and the NIS domain name to the client. The client then automatically becomes a NIS client. If a DHCP client system is already running the Solaris operating environment, the NIS client is not automatically configured on that system when the DHCP server sends NIS information to the client.  If the DHCP server is configured to send NIS information to the DHCP client system, you can see the values given to the client if you use the dhcpinfo command on the client as follows: # /sbin/dhcpinfo NISdmain # /sbin/dhcpinfo NISservs Use the values returned for the NIS domain name and NIS servers when you set up the system as a NIS client.   You set up a NIS client for a Solaris DHCP client system in the standard way, as documented in “Configuring NIS Service” in Solaris Naming Setup and Configuration Guide. Note – You can write a script that uses dhcpinfo and ypinit to automate NIS client configuration on DHCP client systems.
NIS+	If the DHCP client system receives a nonreserved IP address (the address may not always be the same), you must set up the NIS+ client for a DHCP client system in a nonstandard way, which is documented in Setting Up DHCP Clients as NIS+ Clients. This procedure is necessary because NIS+ uses security measures to authenticate requests for service. The security measures depend upon the IP address. If the DHCP client system has been manually assigned an IP address (the client's address is always the same), you can set up the NIS+ client in the standard way, which is documented in “Configuring NIS+ Clients” in Solaris Naming Setup and Configuration Guide
/etc/inet/hosts	You must set up the /etc/inet/hosts file for a DHCP client system that is to use /etc/inet/hosts for its name service. The DHCP client system's host name is added to its own /etc/inet/hosts file by the DHCP tools. However, you must add the host name manually to the /etc/inet/hosts files of other systems in the network. If the DHCP server system uses /etc/inet/hosts for name resolution, you must also add the client's host name manually on the system.
DNS	If the DHCP client system receives the DNS domain name through DHCP, the client system's /etc/resolv.conf file is configured automatically. To actually use DNS on systems that use /etc/inet/hosts files, you must modify the /etc/nsswitch.conf file to add dns to the hosts line, as shown in “Default nsswitch.files File” in Solaris Naming Setup and Configuration Guide If the client system uses NIS or NIS+ for local name resolution, you should be aware of the following:   NIS – If the NIS server allows DNS forwarding (which it does by default), the NIS client system can also use DNS. No further DNS client setup is needed in this case. If the NIS server does not allow DNS forwarding, the client system can use DNS by becoming a DNS client as described in “Setting Up DNS Clients” in Solaris Naming Setup and Configuration Guide. Note that if the client receives the DNS domain name from the DHCP server, the /etc/resolv.conf file needed for a DNS client is configured automatically, so you need only be concerned with the nsswitch.conf file. NIS+ – The NIS+ client system can be configured to also use DNS if you edit the nsswitch.conffile as described in “Modifying the /etc/nsswitch.conf File” in Solaris Naming Setup and Configuration Guide.

Client Host Name Registration

If you let the DHCP server generate host names for the IP addresses you place in the DHCP service, the DHCP server can register those host names in NIS+, /etc/inet/hosts, or DNS name services. Host name registration cannot be done in NIS because NIS does not provide a protocol to allow programs to update and propagate NIS maps.

---

Note –

The DHCP server can update DNS with generated host names only if the DNS server and DHCP server are running on the same system.

---

If a DHCP client provides its host name and the DNS server is configured to allow dynamic updates from the DHCP server, the DHCP server can update DNS on the client's behalf, even if the DNS and DHCP servers are running on different systems. See Enabling Dynamic DNS Updates by DHCP Server for more information about enabling this feature.

The following table summarizes client host name registration for DHCP client systems with the various name services.

Table 1–5 Client Host Name Registration in Name Services

	Who Registers Host Name
Name Service	DHCP Generated Host Name	DHCP Client Supplied Host Name
NIS	NIS Administrator	NIS Administrator
NIS+	DHCP tools	DHCP tools
/etc/hosts	DHCP tools	DHCP tools
DNS	DHCP tools, if the DNS server runs on the same system as the DHCP server.  DNS Administrator, if the DNS sever runs on a different system.	DHCP server, if configured for dynamic DNS updates.   DNS Administrator, if DHCP server is not so configured.

Note that Solaris DHCP clients can request particular host names in DHCP requests if configured to do so as described in How to Enable a Solaris Client to Request Specific Host Name. Please consult the documentation for non-Solaris clients to determine if the capability is supported.

DHCP Client Systems With Multiple Network Interfaces

The DHCP client daemon can manage several different interfaces on one system simultaneously, each with its own IP address and lease time. If more than one network interface is configured for DHCP, the client issues separate requests to configure them and maintains a separate set of network configuration options for each interface. However, although the parameters are stored separately, some of the parameters are global in nature, applying to the system as a whole, rather than to a particular network interface.

Options such as hostname, NIS domain name, and timezone are global parameters and should have the same values for each interface, but these values may differ due to errors in the information entered by the DHCP administrator. To ensure that there is only one answer to a query for a global parameter, only the parameters for the primary network interface are requested. You can insert the word primary in the /etc/dhcp.interface file for the interface you want to be treated as the primary interface.