What information must be provided in order to configure an ipv6 dhcp scope?

This chapter discusses the Dynamic Host Configuration Protocol (DHCP) client that is part of the Solaris Operating System. The chapter explains how the client's DHCPv4 and DHCPv6 protocols work, and how you can affect the behavior of the client.

One protocol, DHCPv4, has long been part of the Solaris Operating System (Solaris OS), and enables DHCP servers to pass configuration parameters such as IPv4 network addresses to IPv4 nodes.

The other protocol, DHCPv6, enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. DHCPv6 is a stateful counterpart to “IPv6 Stateless Address Autoconfiguration” (RFC 2462), and can be used separately or concurrently with the stateless to obtain configuration parameters.

This chapter contains the following information:

The Solaris DHCP client is the dhcpagent daemon, part of the Solaris OS. When you install the Solaris OS, you are prompted to use DHCP to configure network interfaces. If you specify Yes for DHCPv4, then that protocol is enabled on your system during Solaris installation. There are no install time options specifically for DHCPv6. A related question, though, is about IPv6. If you enable IPv6, then DHCPv6 is also enabled on a local network that supports DHCPv6.

You do not need to do anything else with the Solaris client to use DHCP. The DHCP server's configuration determines what information is given to DHCP client systems that use the DHCP service.

If a client system is already running the Solaris OS, but not using DHCP, you can reconfigure the client system to use DHCP. You can also reconfigure a DHCP client system so that it stops using DHCP and uses static network information that you provide. See Enabling and Disabling a Solaris DHCP Client for more information.

DHCPv6 Server

There is no DHCPv6 server available through Sun Microsystems for the Solaris OS. Servers available from third parties are compatible with Sun's DHCPv6, and if there is a DHCPv6 server on the network, Sun's DHCPv6 client will use it.

See Solaris DHCP Serverfor information on the Sun DHCPv4 server.

Differences Between DHCPv4 and DHCPv6

The two major differences between DHCPv4 and DHCPv6 are the following:

• The administrative model

  • DHCPv4–The administrator enables DHCP for each interface. Administration is on a per-logical interface basis.

  • DHCPv6–Explicit configuration is not necessary. This protocol is enabled on a given physical interface.

• Protocol details

  • DHCPv4–The DHCP server supplies the subnet mask for each address. A hostname option sets the system-wide node name.

  • DHCPv6–The subnet mask is supplied by Router Advertisements, not the DHCPv6 server. There is no DHCPv6 hostname option.

The Administrative Model

DHCPv4 requires explicit client configuration. You must set up the DHCPv4 system for addressing when desired, and this is typically done during initial system installation or dynamically through the use of ifconfig(1M) options.

DHCPv6 does not require explicit client configuration. Instead, using DHCP is a property of the network, and the signal to use it is carried in Router Advertisement messages from local routers. The DHCP client automatically creates and destroys logical interfaces as needed.

The DHCPv6 mechanism is very similar administratively to the existing IPv6 stateless (automatic) address configuration. For stateless address configuration, you would set a flag on the local router to indicate that, for a given set of prefixes, each client should automatically configure an address on its own by using the advertised prefix plus a local interface token or random number. For DHCPv6, the same prefixes are required, but the addresses are acquired and managed through a DHCPv6 server instead of being assigned “randomly.”

MAC Address and Client ID

DHCPv4 uses the MAC address and an optional Client ID to identify the client for purposes of assigning an address. Each time the same client arrives on the network, it gets the same address, if possible.

DHCPv6 uses basically the same scheme, but makes the Client ID mandatory and imposes structure on it. The Client ID in DHCPv6 consists of two parts: a DHCP Unique Identifier (DUID) and an Identity Association Identifier (IAID). The DUID identifies the client system (rather than just an interface, as in DHCPv4), and the IAID identifies the interface on that system.

As described in RFC 3315, an identity association is the means used for a server and a client to identify, group, and manage a set of related IPv6 addresses. A client must associate at least one distinct IA with each of its network interfaces, and then uses the assigned IAs to obtain configuration information from a server for that interface. For additional information about IAs, see the next section, “Protocol Details.”

DUID+IAID can also be used with DHCPv4. These can be concatenated together unambiguously so that they can serve as the Client ID. For compatibility reasons, this is not done for regular IPv4 interfaces. However, for logical interfaces ("hme0:1"), DUID+IAID is used if no Client ID is configured.

Unlike IPv4 DHCP, DHCPv6 does not provide a “client name” option, so there is no way to name your systems based on DHCPv6 alone. Instead, if you need to know the DNS name that goes with an address provided by DHCPv6, use DNS reverse-resolution (address-to-name query via the getaddrinfo(3SOCKET) function) to find the corresponding name information. One implication of this is that if you are using only DHCPv6 and want a node to have a specific name, you must set /etc/nodename on your system.

Protocol Details

With DHCPv4, the DHCP server supplies the subnet mask to be used with the assigned address. With DHCPv6, the subnet mask (also known as “prefix length”) is assigned by the Router Advertisements, and is not controlled by the DHCP server.

DHCPv4 carries a Hostname option that is used to set the system-wide node name. DHCPv6 has no such option.

To configure a Client ID for DHCPv6 you must specify a DUID, rather than allowing the system to choose one automatically. You can do this globally for the daemon, or on a per-interface basis. Use the following format to set the global DUID (note the initial dot):

.v6.CLIENT_ID=

To set a particular interface to use a given DUID (and make the system appear to be multiple independent clients to a DHCPv6 server):

hme0.v6.CLIENT ID=

Each Identity Association (IA) holds one type of address. For example, an identity association for temporary addresses (IA_TA) holds temporary addresses, while an identity association for non-temporary addresses (IA_NA), carries assigned addresses that are permanent. The version of DHCPv6 described in this guide provides only IA_NA associations.

The Solaris OS assigns exactly one IAID to each interface, on demand, and the IAID is stored in a file in the root file system so that it remains constant for the life of the machine.

Logical Interfaces

In the DHCPv4 client, each logical interface is independent and is an administrative unit. In addition to the zeroth logical interface (which defaults to the interface MAC address as an identifier), the user may configure specific logical interfaces to run DHCP by specifying a CLIENT_ID in the dhcpagent configuration file. For example:

hme0:1.CLIENT_ID=orangutan

DHCPv6 works differently. The zeroth logical interface on an IPv6 interface, unlike IPv4, is always a link-local. A link-local is used to automatically assign an IP address to a device in an IP network when there is no other assignment method available, such as a DHCP server. The zeroth logical interface cannot be under DHCP control, so although DHCPv6 is run on the zeroth logical interface (known, also, as the “physical” interface), it assigns addresses only on non-zero logical interfaces.

In response to a DHCPv6 client request, the DHCPv6 server returns a list of addresses for the client to configure.

Option Negotiation

In DHCPv6 there is an Option Request Option, which provides a hint to the server of what the client prefers to see. If all possible options were sent from the server to the client, so much information could be sent that some of it would have to be dropped on the way to the client. The server might use the hint to choose among the options to include in the reply. Alternatively, the server could ignore the hint and choose other items to include. On Solaris OS, for example, the preferred options might include the Solaris DNS address domain or the NIS address domain, but would probably not include the net bios server.

The same type of hint is also provided for DHCPv4, but without the special Option Request Option. Instead DHCPv4 uses the PARAM_REQUEST_LIST in /etc/default/dhcpagent.

Configuration Syntax

Configure the DHCPv6 client in much the same way as the existing DHCPv4 client, using /etc/default/dhcpagent.

The syntax is augmented with a “.v6” marker between the interface name (if any) and the parameter to be configured. For example, the global IPv4 option request list is set like this:

PARAM_REQUEST_LIST=1,3,6,12,15,28,43

An individual interface can be configured to omit the hostname option like this:

hme0.PARAM_REQUEST_LIST=1,3,6,15,28,43

To set a global request list for DHCPv6, note the leading dot:

.v6.PARAM_REQUEST_LIST=23,24

Or, to set an individual interface, follow this example:

hme0.v6.PARAM_REQUEST_LIST=21,22,23,24

For reference, here is an actual /etc/default/dhcpagent file for DHCPv6 configuration:

# The default DHCPv6 parameter request list has preference (7), unicast (12),
# DNS addresses (23), DNS search list (24), NIS addresses (27), and
# NIS domain (29).  This may be changed by altering the following parameter- 
# value pair.  The numbers correspond to the values defined in RFC 3315 and 
# the IANA dhcpv6-parameters registry. 
.v6.PARAM_REQUEST_LIST=7,12,23,24,27,29

DHCP Client Startup

In most cases, there is nothing you need to do for DHCPv6 client startup. The in.ndpd daemon starts up DHCPv6 automatically when it is needed. You might need to touch /etc/hostname6.$IFNAME to configure an interface to be plumbed for IPv6 at boot time. However, the installer already does this if you enable IPv6 on your system at install time.

For DHCPv4, however, you must request the client startup, if that was not done during Solaris installation. See How to Enable the Solaris DHCP Client.

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.

Although the default is to run DHCPv6, you can choose to not have DHCPv6 run. After DHCPv6 starts running, you can stop it with the ifconfig command. You can also disable DHCPv6 so that it does not start on reboot, by modifying the /etc/inet/ndpd.conf file.

For example, to immediately shut down DHCPv6 on the interface named “hme0.”

ex# echo ifdefault StatefulAddrConf false >> /etc/inet/ndpd.conf  
ex# pkill -HUP -x in.ndpd   
ex# ifconfig hme0 inet6 dhcp release

The presence of the file /etc/dhcp.interface (for example, /etc/dhcp.ce0 on a Sun FireTM 880 system) indicates to the startup scripts that DHCPv4 is to be used on the specified interface. Upon finding a dhcp.interface file, the startup scripts start dhcpagent.

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 DHCPv4 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 ifconfig interface dhcp command.

DHCPv6 Communication

Unlike DHCPv4, which is invoked by manual configuration, DHCPv6 is invoked by Router Advertisements (RAs). Depending on how the router is configured, the system automatically invokes DHCPv6 on the interface on which the Router Advertisement message was received and uses DHCP to get an address and other parameters, or the system requests only data other than an address (for example, DNS servers) with DHCPv6.

The in.ndpd daemon receives the Router Advertisement message. It does this automatically on all interfaces plumbed for IPv6 on the system. When in.ndpd sees an RA that specifies that DHCPv6 should run, it invokes it.

To prevent in.ndpd from starting up DHCPv6, you can change the /etc/inet/ndpd.conf file.

You can also stop DHCPv6 after it starts by using one of the following versions of ifconfig:

ifconfiginet6 dhcp drop

or:

ifconfiginet6 dhcp release

How DHCP Client Protocols Manage Network Configuration Information

DHCPv4 and DHCPv6 client protocols manage network configuration information in different ways. The key difference is that with DHCPv4 the negotiation is for the lease of a single address and some options to go with it. With DHCPv6, the negotiation is over a batch of addresses and a batch of options.

For background information on the interaction between DHCPv4 client and server, see Chapter 11, About Solaris DHCP (Overview).

How the DHCPv4 Client Manages Network Configuration Information

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

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

Each time dhcpagent performs an action related to the lease, the daemon looks for an executable file called /etc/dhcp/eventhook. If an executable file with this name is found, dhcpagent invokes the executable. See DHCP Client Event Scripts for more information about using the event executable.

How the DHCPv6 Client Manages Network Configuration Information

DHCPv6 communication between client and server begins with the client sending out a Solicit message, to locate servers. In response, all servers available for DHCP service send an Advertise message. The server message contains multiple IA_NA (Identity Association Non-Temporary Address) records plus other options (such as DNS server addresses) that the server can supply.

A client can request particular addresses (and multiples of them) by setting up its own IA_NA/IAADDR records in its Request message. A client typically requests specific addresses if it has old addresses recorded and it would like the server to provide the same ones, if possible. Regardless of what the client does (even if it requests no addresses at all), the server can supply any number of addresses to the client for a single DHCPv6 transaction.

This is a the message dialog that takes place between the clients and servers.

• A client sends a Solicit message to locate servers.

• Servers send an Advertise message to indicate they are available for DHCP service.

• A client sends a Request message to request configuration parameters, including IP addresses, from servers with the greatest preference values. Server preference values are set by the administrator and extend from 0, at the lowest end, to 255 at the highest.

• The server sends a Reply message that contains the address leases and configuration data.

If the preference value in the Advertise message is 255, the DHCPv6 client immediately selects that server. If the most preferred server does not respond, or fails to give a successful Reply to the Request message, then the client continues looking for less-preferred servers (in order) until there are no more Advertise messages on hand. At that point, the client starts over by again sending Solicit messages.

The chosen server sends a Reply message containing assigned addresses and configuration parameters in response to a Solicit or Request message.

DHCP Client Shutdown

At shutdown, the client sends a Release message to the server that assigned addresses to the client, to indicate that the client will no longer use one or more of the assigned addresses. When the DHCPv4 client system shuts down normally, dhcpagent writes the current configuration information to the file /etc/dhcp/interface.dhc, or for DHCPv6, to /etc/dhcp/interface.dh6. By default, the lease is saved rather than released, so the DHCP server does not know that the IP address is not in active use, which enables the client to easily regain the address on next boot. This default action is the same as the ifconfigdhcp dropcommand.

If the lease in that file is still valid when the system reboots, dhcpagent sends an abbreviated request to use the same IP address and network configuration information. For DHCPv4, this is the Request message. For DHCPv6, the message is Confirm.

If the DHCP server permits this request, dhcpagent 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, dhcpagent initiates the DHCP protocol sequence described in How DHCP Works. As a result, the client obtains new network configuration information.

To enable the DHCP client on a system that is already running the Solaris OS and is not using DHCP, you must first unconfigure the system. When the system boots, you must issue some commands to set up the system and enable the DHCP client.

In many deployments it is common practice to have crucial parts of the infrastructure set up with static IP addresses, rather than using DHCP. Determining which devices on your network, for example routers and certain servers, should be client and which should not, is beyond the scope of this guide.

How to Enable the Solaris DHCP Client

This procedure is necessary only if DHCPv4 was not enabled during Solaris installation. It is never necessary for DHCPv6.

1. Become superuser on the client system.

2. If this system uses preconfiguration instead of interactive configuration, edit the sysidcfg file. Add the dhcp subkey to the network_interface keyword in the sysidcfg file.

   For example, network_interface=hme0 {dhcp}. See the sysidcfg(4) man page for more information.

3. Unconfigure and shut down the system.

   See the sys-unconfig(1M) man page for more information about the configuration information that is removed by this command.

4. Reboot the system after shutdown is complete.

   If the system uses preconfiguration, the dhcp subkey in the sysidcfg file configures the system to use the DHCP client as the system boots.

   If the system does not use preconfiguration, you are prompted for system configuration information by sysidtool programs when the system reboots. See the sysidtool(1M) man page for more information.

5. When prompted to use DHCP to configure network interfaces, specify Yes.

How to Disable a Solaris DHCP Client

1. Become superuser on the client system.

2. If you used a sysidcfg file to preconfigure the system, remove the dhcp subkey from the network_interface keyword.

3. Unconfigure and shut down the system.

   See the sys-unconfig(1M) man page for more information about the configuration information that is removed by this command.

4. Reboot the system after shutdown is complete.

   If the system uses preconfiguration, you are not prompted for configuration information, and the DHCP client is not configured.

   If the system does not use preconfiguration, you are prompted for system configuration information by sysidtool programs when the system reboots. See the sysidtool(1M) man page for more information.

5. When prompted to use DHCP to configure network interfaces, specify No.

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

ifconfig Command Options Used With the DHCP Client

This section summarizes the command options, which are documented in the ifconfig(1M) man page. The only difference between the DHCPv4 and the DHCPv6 versions of these commands is the “inet6” keyword. Include the “inet6” keyword for DHCPv6, but leave it out when running DHCPv4.

The ifconfig command enables you to do the following:

• Start the DHCP client – The command ifconfig interface [inet6] dhcp start initiates the interaction between dhcpagent and the DHCP server to obtain an IP address and a new set of configuration options. This command is 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 [inet6] dhcp inform causes dhcpagent to issue a request for network configuration parameters, with the exception of the IP address. This command is useful when the network interface has a static IP address, but the client system needs updated network options. For example, this command is useful if you do not use DHCP to manage IP addresses, but you do use it to configure hosts on the network.

• Request a lease extension – The command ifconfig interface [inet6] dhcp extend causes dhcpagent to issue a request to renew the lease. The client does automatically request to renew leases. However, 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 [inet6] dhcp release causes dhcpagent to relinquish the IP address used by the network interface. Release of the IP address happens automatically when the lease expires. You might want to issue this command with a laptop, for example, when leaving a network and planning to start the system on a new network. See also the /etc/default/dhcpagent configuration file RELEASE_ON_SIGTERM property.

• Drop the IP address – The command ifconfig interface [inet6] dhcp drop causes dhcpagent to take down the network interface without informing the DHCP server and cache the lease in the file system. This command enables the client to use the same IP address when it reboots.

• Ping the network interface – The command ifconfig interface [inet6] dhcp ping lets you determine if the interface is under the control of DHCP.

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

  • If an IP address has been bound to the client

  • The number of requests sent, received, and declined

  • If this interface is the primary interface

  • Times when the lease was obtained, when it expires, and when renewal attempts are scheduled to begin

  For example:

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

  # ifconfig hme0 inet6 dhcp status
  Interface  State         Sent  Recv  Declined  Flags 
  hme0       BOUND            1     0         0   [PRIMARY]  
  (Began,Expires,Renew)=(11/22/2006 20:39, 11/22/2006 20:41, 11/22/2006 20:40)

Setting DHCP Client Configuration Parameters

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

The /etc/dhcp.interface file is another location in which parameters affecting the DHCP client are set. Parameters set in this file are used by system startup scripts with the ifconfig command. This, however, affects only DHCPv4. There is no DHCPv6 equivalent.

By default, the DHCP client is configured as follows:

For DHCPv4

• The client system does not require a particular host name.

  If you want a client to request a specific host name, see DHCPv4 Client Host Names.

• Default requests for the client are given in /etc/default/dhcpagent, and includes DNS Server, DNS domain, and broadcast address.

  The DHCP client's parameter file can be set up to request more options in the PARAM_REQUEST_LIST keyword in the /etc/default/dhcpagent file. The DHCP server can be configured to provide options that were not specifically requested. See About DHCP Macros and Working With DHCP Macros (Task Map) for information about using DHCP server macros to send information to clients.

For DHCPv4 and DHCPv6

The DHCP client can simultaneously manage several different interfaces on one system. The interfaces can be physical interfaces or logical interfaces. Each interface has 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. The client maintains a separate set of network configuration parameters for each interface. Although the parameters are stored separately, some of the parameters are global in nature. The global parameters apply to the system as a whole, rather than to a particular network interface.

The host name, NIS domain name, and time zone are examples of global parameters. Global parameters usually have different values for each interface. However, only one value can be used for each global parameter associated with each system. To be sure that there is only one answer to a query for a global parameter, only the parameters for the primary network interface are used. You can insert the word primary in the /etc/dhcp.interface file for the interface that you want to be treated as the primary interface. If the primary keyword is not used, the first interface in alphabetical order is considered to be the primary interface.

The DHCP client manages leases for logical interfaces and physical interfaces identically, except for the following limitation on logical interfaces:

• The DHCP client does not manage the default routes that are associated with logical interfaces.

  The Solaris kernel associates routes with physical interfaces, not logical interfaces. When a physical interface's IP address is established, the necessary default routes should be placed in the routing table. If DHCP is used subsequently to configure a logical interface associated with that physical interface, the necessary routes should already be in place. The logical interface uses the same routes.

  When a lease expires on a physical interface, the DHCP client removes the default routes that are associated with the interface. When a lease expires on a logical interface, the DHCP client does not remove the default routes associated with the logical interface. The associated physical interface and possibly other logical interfaces might need to use the same routes.

  If you need to add or remove default routes that are associated with a DHCP-controlled interface, you can use the DHCP client event script mechanism. See DHCP Client Event Scripts.

By default, the Solaris DHCPv4 client does not supply its own host name, because the client expects the DHCP server to supply the host name. The Solaris DHCPv4 server is configured to supply host names to DHCPv4 clients by default. When you use the Solaris DHCPv4 client and server together, these defaults work well. However, when you use the Solaris DHCPv4 client with some third-party DHCP servers, the client might not receive a host name from the server. If the Solaris DHCP client does not receive a host name through DHCP, the client system looks at the /etc/nodename file for a name to use as the host name. If the file is empty, the host name is set to unknown.

If the DHCP server supplies a name in the DHCP Hostname option, the client uses that host name, even if a different value is placed in the /etc/nodename file. If you want the client to use a specific host name, you can enable the client to request that name. See the following procedure.

The following procedure does not work with all DHCP servers. Through this procedure you are requiring the client to send a specific host name to the DHCP server, and to expect the same name in return.

However, the DHCP server does not have to respect this request and many do not. They simply return a different name.

How to Enable a Solaris DHCPv4 Client to Request a Specific Host Name

1. On the client system, edit the /etc/default/dhcpagent file as superuser.

2. Find the REQUEST_HOSTNAME keyword in the /etc/default/dhcpagent file and modify the keyword as follows:

   If a comment sign (#) is in front of REQUEST_HOSTNAME, remove the #. If the REQUEST_HOSTNAME keyword is not present, insert the keyword.

3. Edit the /etc/hostname.interface file on the client system to add the following line:

   inet hostname
   

   hostname is the name that you want the client to use.

4. Type the following commands to have the client perform a full DHCP negotiation upon rebooting:

   # ifconfig interface dhcp release
   # reboot
   

   The DHCP data that is cached on the client is removed. The client restarts the protocol to request new configuration information, including a new host name. The DHCP server first makes sure that the host name is not in use by another system on the network. The server then assigns the host name to the client. If configured to do so, the DHCP server can update name services with the client's host name.

   If you want to change the host name later, repeat Step 3 and Step 4.

Solaris systems support the following name services: DNS, NIS, NIS+, and a local file store (/etc/inet/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. By default, and unless configured otherwise during system installation, only local files are used.

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

Name Service  

Client Setup Information 

NIS 

If you are using Solaris DHCP to send Solaris network install information to a client system, you can use a configuration macro that contains the NISservs and NISdmain options. These options pass the IP addresses of NIS servers and the NIS domain name to the client. The client then automatically becomes an NIS client.

If a DHCP client system is already running the Solaris OS, 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

For DHCPv6, include -v6, and different protocol keywords in the command.

# /sbin/dhcpinfo -v6 NISDomain

# /sbin/dhcpinfo -v6 NISServers

Use the values returned for the NIS domain name and NIS servers when you set up the system as an NIS client. 

You set up an NIS client for a Solaris DHCP client system in the standard way, as documented in Chapter 5, Setting Up and Configuring NIS Service, in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

You can write a script that uses dhcpinfo and ypinit to automate NIS client configuration on DHCP client systems.

NIS+ 

If the NIS+ client for a DHCP client system is set up in the conventional way, then the DHCP server might give the client different addresses from time to time. This creates security issues, because NIS+ security includes IP address as part of the configuration. To assure that your client has the same address every time, 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.

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 Setting Up NIS+ Client Machines in System Administration Guide: Naming and Directory Services (NIS+).

/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 manually add the host name 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 manually add the client's host name 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. The /etc/nsswitch.conf file is also automatically updated to append dns to the hosts line after any other name services in the search order. See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for more information about DNS.

Setting Up DHCP Clients as NIS+ Clients

You can use the NIS+ name service on Solaris systems that are DHCP clients. However, if your DHCP server can provide different addresses at different times, this partially circumvents one of the security-enhancing features of NIS+, the creation of Data Encryption Standard (DES) credentials. For the sake of security, configure the DHCP server to provide the same address all the time. When you set up an NIS+ client that is not using DHCP, you add unique DES credentials for the client to the NIS+ server. There are several ways to create credentials, such as using the nisclient script or the nisaddcred command.

NIS+ credential generation requires a client to have a static host name to create and store the credentials. If you want to use NIS+ and DHCP, you must create identical credentials to be used for all the host names of DHCP clients. In this way, no matter what IP address and associated host name that a DHCP client receives, the client can use the same DES credentials.

The following procedure shows you how to create identical credentials for all DHCP host names. This procedure is valid only if you know the host names that DHCP clients use. For example, when the DHCP server generates the host names, you know the possible host names that a client can receive.

How to Set Up Solaris DHCP Clients as NIS+ Clients

A DHCP client system that is to be an NIS+ client must use credentials that belong to another NIS+ client system in the NIS+ domain. This procedure only produces credentials for the system, which apply only to the superuser logged in to the system. Other users who log in to the DHCP client system must have their own unique credentials in the NIS+ server. These credentials are created according to a procedure in the System Administration Guide: Naming and Directory Services (NIS+).

1. Create the credentials for a client by typing the following command on the NIS+ server:

   # nisgrep nisplus-client-name cred.org_dir > /tmp/file
   

   This command writes the cred.org_dir table entry for the NIS+ client to a temporary file.

2. Use the cat command to view the contents of the temporary file.

   Or, use a text editor.

3. Copy the credentials to use for DHCP clients.

   You must copy the public key and private key, which are long strings of numbers and letters separated by colons. The credentials are to be pasted into the command issued in the next step.

4. Add credentials for a DHCP client by typing the following command:

   # nistbladm -a cname=" dhcp-client-name@nisplus-domain" auth_type=DES \
   auth_name="unix.dhcp-client-name@nisplus-domain" \
   public_data=copied-public-key \ 
   private_data=copied-private-key
   

   For the copied-public-key, paste the public key information that you copied from the temporary file. For the copied-private-key, paste the private key information that you copied from the temporary file.

5. Remote copy files from the NIS+ client system to the DHCP client system by typing the following commands on the DHCP client system:

   # rcp nisplus-client-name:/var/nis/NIS_COLD_START /var/nis
   # rcp nisplus-client-name:/etc/.rootkey /etc
   # rcp nisplus-client-name:/etc/defaultdomain /etc
   

   If you get a “permission denied” message, the systems might not be set up to allow remote copying. In this case, you can copy the files as a regular user to an intermediate location. As superuser, copy the files from the intermediate location to the proper location on the DHCP client system.

6. Copy the correct name service switch file for NIS+ by typing the following command on the DHCP client system:

   # cp /etc/nsswitch.nisplus /etc/nsswitch.conf
   

7. Reboot the DHCP client system.

   The DHCP client system should now be able to use NIS+ services.

Example 15–1 Setting up a Solaris DHCP Client System as an NIS+ Client

The following example assumes that you have one system nisei, which is an NIS+ client in the NIS+ domain dev.example.net. You also have one DHCP client system, dhow, and you want dhow to be an NIS+ client.

ex# echo ifdefault StatefulAddrConf false >> /etc/inet/ndpd.conf  
ex# pkill -HUP -x in.ndpd   
ex# ifconfig hme0 inet6 dhcp release

The DHCP client system dhow should now be able to use NIS+ services.

Example 15–2 Adding Credentials With a Script

If you want to set up a large number of DHCP client systems as NIS+ clients, you can write a script. A script can quickly add the entries to the cred.org_dir NIS+ table. The following example shows a sample script.

ex# echo ifdefault StatefulAddrConf false >> /etc/inet/ndpd.conf  
ex# pkill -HUP -x in.ndpd   
ex# ifconfig hme0 inet6 dhcp release

You can set up the Solaris DHCP client to run an executable program or script that can perform any action that is appropriate for the client system. The program or script, which is called an event script, is automatically executed after certain DHCP lease events occur. The event script can be used to run other commands, programs, or scripts in response to specific lease events. You must provide your own event script to use this feature.

The following event keywords are used by dhcpagent to signify DHCP lease events:

Description

The interface is configured for DHCP. The client receives the acknowledgement message (DHCPv4 ACK) or (DHCPv6 Reply) from the DHCP server, which grants the lease request for an IP address. The event script is invoked immediately after the interface is configured successfully.

The client successfully extends a lease. The event script is invoked immediately after the client receives the acknowledgement message from the DHCP server for the renew request.

The lease expires when the lease time is up. For DHCPv4, the event script is invoked immediately before the leased address is removed from the interface and the interface is marked as down. For DHCPv6, the event script is invoked just before the last remaining leased addresses are removed from the interface.

The client drops the lease to remove the interface from DHCP control. The event script is invoked immediately before the interface is removed from DHCP control.

The client relinquishes the IP address. The event script is invoked immediately before the client releases the address on the interface and sends the DHCPv4 RELEASE or DHCPv6 Release packet to the DHCP server.

An interface acquires new or updated configuration information from a DHCP server through the DHCPv4 INFORM or the DHCPv6 Information-Request message. These events occur when the DHCP client obtains only configuration parameters from the server and does not obtain an IP address lease.

During lease expiration, when one or more valid leases still remain, the event script is invoked just before expired addresses are removed. Those being removed are marked with the IFF_DEPRECATED flag.

With each of these events, dhcpagent invokes the following command:

ex# echo ifdefault StatefulAddrConf false >> /etc/inet/ndpd.conf  
ex# pkill -HUP -x in.ndpd   
ex# ifconfig hme0 inet6 dhcp release

where interface is the interface that is using DHCP and event is one of the event keywords described previously. For example, when the ce0 interface is first configured for DHCP, the dhcpagent invokes the event script as follows:

ex# echo ifdefault StatefulAddrConf false >> /etc/inet/ndpd.conf  
ex# pkill -HUP -x in.ndpd   
ex# ifconfig hme0 inet6 dhcp release

To use the event script feature, you must do the following:

• Name the executable file /etc/dhcp/eventhook.

• Set the owner of the file to be root.

• Set permissions to 755 (rwxr-xr-x).

• Write the script or program to perform a sequence of actions in response to any of the documented events. Because Sun might add new events, the program must silently ignore any events that are not recognized or do not require action. For example, the program or script might write to a log file when the event is RELEASE, and ignore all other events.

• Make the script or program noninteractive. Before the event script is invoked, stdin, stdout, and stderr are connected to /dev/null. To see the output or errors, you must redirect to a file.

The event script inherits its program environment from dhcpagent, and runs with root privileges. The script can use the dhcpinfo utility to obtain more information about the interface, if necessary. See the dhcpinfo(1) man page for more information.

The dhcpagent daemon waits for the event script to exit on all events. If the event script does not exit after 55 seconds, dhcpagent sends a SIGTERM signal to the script process. If the process still does not exit after three additional seconds, the daemon sends a SIGKILL signal to kill the process.

The dhcpagent(1M) man page includes one example of an event script.

Example 15–3 shows how to use a DHCP event script to keep the content of the /etc/resolv.conf file up to date. When the BOUND and EXTEND events occur, the script replaces the names of the domain server and name server. When the EXPIRE, DROP and RELEASE events occur, the script removes the names of the domain server and name server from the file.

The example script assumes that DHCP is the authoritative source for the names of the domain server and the name server. The script also assumes that all interfaces under DHCP control return consistent and current information. These assumptions might not reflect conditions on your system.

How to configure DHCP for IPv6?

How to configure DHCP scope?

What are the 3 options for a host to configure an IPv6 address?

What are the mandatory minimum configurations that must be configured on a DHCP server?