Chapter 6 - Dynamic Host Configuration Protocol

Artigo
08/31/2011

Abstract

This chapter describes the details of the Dynamic Host Configuration Protocol (DHCP) and its use to automatically allocate unique IPv4 address configurations to DHCP client computers. Network administrators must understand how DHCP works so that they can correctly configure the components of a DHCP infrastructure to allocate IPv4 addresses and other configuration options for DHCP clients on one or more subnets. This chapter also describes how IPv6 hosts use address autoconfiguration and how you can manage IP configuration with the Ipconfig tool.

For a download of the entire "TCP/IP Fundamentals for Microsoft Windows" online book, which contains a version of this chapter that has been updated for Windows Vista and Windows Server 2008, click here.

Chapter Objectives

After completing this chapter, you will be able to:

Describe the function of DHCP.
Explain how DHCP works.
Install and configure the DHCP Server service.
Configure a DHCP scope, a superscope, and scope options.
Describe the function of DHCP user and vendor classes.
Install and configure a DHCP relay agent.
Describe how IPv6 address autoconfiguration works.
Use the Ipconfig tool to view IP configurations and to manage DHCP-allocated IPv4 address configurations.

DHCP Overview

DHCP is a TCP/IP standard that reduces the complexity and administrative overhead of managing network client IPv4 addresses and other configuration parameters. A properly configured DHCP infrastructure eliminates the configuration problems associated with manually configuring TCP/IP.

A DHCP infrastructure consists of the following elements:

DHCP servers

Computers that offer dynamic configuration of IPv4 addresses and related configuration parameters to DHCP clients.
DHCP clients

Network nodes that support the ability to communicate with a DHCP server to obtain a dynamically leased IPv4 address and related configuration parameters.
DHCP relay agents

Network nodes, typically routers, that listen for broadcast and unicast DHCP messages and relay them between DHCP servers and DHCP clients. Without DHCP relay agents, you would have to install a DHCP server on each subnet that contains DHCP clients.

Each time a DHCP client starts, it requests IPv4 addressing information from a DHCP server, including:

IPv4 address
Subnet mask
Additional configuration parameters, such as a default gateway address, Domain Name System (DNS) server addresses, a DNS domain name, and Windows Internet Name Service (WINS) server addresses.

When a DHCP server receives a request, it selects an available IPv4 address from a pool of addresses defined in its database (along with other configuration parameters) and offers it to the DHCP client. If the client accepts the offer, the IPv4 addressing information is leased to the client for a specified period of time.

The DHCP client will typically continue to attempt to contact a DHCP server if a response to its request for an IPv4 address configuration is not received, either because the DHCP server cannot be reached or because no more IPv4 addresses are available in the pool to lease to the client. For DHCP clients that are based on Microsoft® Windows® XP or Windows Server 2003™ operating systems, the DHCP Client service uses the alternate configuration when it cannot contact a DHCP server. The alternate configuration can be either an Automatic Private IP Addressing (APIPA) address or an alternate configuration that has been configured manually.

Requests for Comments (RFCs) 2131 and 2132 define the operation of DHCP clients and servers. RFC 1542 defines the operation of DHCP relay agents. All DHCP messages are sent using the User Datagram Protocol (UDP). DHCP clients listen on UDP port 67. DHCP servers listen on UDP port 68. DHCP relay agents listen on both UDP ports.

Benefits of Using DHCP

To understand why DHCP is beneficial in configuring TCP/IP on client computers, it is useful to contrast the manual configuration method with the DHCP method.

Configuring TCP/IP Manually

Correct operation of TCP/IP on a host computer requires careful configuration of an IPv4 address, subnet mask, and default gateway before the client can communicate with other network nodes. If the configuration is incorrect, the following might happen:

A user who configures a random IPv4 address, instead of getting a valid IPv4 address from a network administrator, can create network problems that are difficult to troubleshoot.
An error in typing one of the numbers for the IPv4 address, subnet mask, or default gateway can also lead to problems. These problems can range from trouble communicating using TCP/IP (if the default gateway or subnet mask is wrong) to problems with attempting to use a duplicate IPv4 address.
If the network node moves to another subnet, the IPv4 address, subnet mask, and default gateway are no longer valid and cannot be used for TCP/IP-based connectivity.

Correct manual configuration is especially important for wireless LANs. For example, a wireless user using a wireless-enabled laptop computer moves from one building to another in a corporate campus. When the user and their laptop change buildings, they might switch to another subnet. Without automated configuration, the user must manually type a different IPv4 address, subnet mask, and default gateway for the new subnet to restore TCP/IP connectivity.

Configuring TCP/IP Using DHCP

Using DHCP to automatically configure IPv4 address configurations means the following:

Users no longer need to acquire IPv4 address configurations from a network administrator to properly configure TCP/IP.

When a DHCP client is started, it automatically receives an IPv4 address configuration that is correct for the attached subnet from a DHCP server. When the DHCP client moves to another subnet, it automatically obtains a new IPv4 address configuration for that subnet.
The DHCP server supplies all of the necessary configuration information to all DHCP clients.

As long as the DHCP server has been correctly configured, all DHCP clients of the DHCP server are configured correctly.

How DHCP Works

DHCP uses the following basic process to automatically configure a DHCP client:

When the TCP/IP protocol initializes and has DHCP enabled on any of its interfaces, the DHCP client sends a DHCPDiscover message to find the DHCP servers on the network and to obtain a valid IPv4 address configuration.
All DHCP servers that receive the DHCPDiscover message and that have a valid IPv4 address configuration for the client send a DHCPOffer message back to the DHCP client.
The DHCP client selects an IPv4 address configuration to use from the DHCPOffer messages that it receives and sends a DHCPRequest message to all the DHCP servers, requesting the use of the selected configuration.

The DHCPRequest message identifies the server that sent the offer that the DHCP client selected. The other DHCP servers that receive the DHCPRequest message that sent offers place their offered IPv4 addresses back into the available pool of addresses.
The selected DHCP server assigns the IPv4 address configuration to the DHCP client and sends a DHCPAck (acknowledgment) message to the DHCP client.

The DHCP client computer finishes initializing the TCP/IP protocol on the interface. Once complete, the client can use all TCP/IP services and applications for normal network communications and connectivity to other IPv4 hosts.

Figure 6-1 shows the basic DHCP process.

Figure 6-1 The basic DHCP process

If a computer has multiple network adapters, the DHCP process occurs separately over each network adapter that is configured for automatic TCP/IP addressing until each network adapter in the computer has been allocated a unique IPv4 address configuration.

DHCP Messages and Client States

The DHCP client can go through six states in the DHCP process:

Initializing
Selecting
Requesting
Bound
Renewing
Rebinding

DHCP clients and servers use the following messages to communicate during the DHCP configuration process:

DHCPDiscover (sent from client to server)
DHCPOffer (sent from server to client)
DHCPRequest (sent from client to server)
DHCPAck (sent from server to client)
DHCPNak (sent from server to client)
DHCPDecline (sent from client to server)
DHCPRelease (sent from client to server)

Figure 6-2 shows DHCP client states and messages, which are discussed in detail in the following sections.

Figure 6-2 DHCP states and messages

Computers running Windows XP or Windows Server 2003 use an additional DHCP message, the DHCPInform message, to request and obtain information from a DHCP server for the following purposes:

To detect authorized DHCP servers in an environment that includes the Active Directory® directory service.
To obtain updated addresses for DNS servers and WINS servers and a DNS domain name when making a remote access connection.
To obtain additional configuration parameters.

The Initializing State

In the Initializing state, the DHCP client is trying to initialize TCP/IP and it does not yet have an IPv4 address configuration. This state occurs the first time the TCP/IP protocol stack is initialized after being configured for automatic configuration and when the DHCP client cannot renew the lease on an IPv4 address configuration.

When the DHCP client is in the Initializing state, its IPv4 address is 0.0.0.0, also known as the unspecified address. The DHCP client's first task is to obtain an IPv4 address configuration by broadcasting a DHCPDiscover message from UDP port 67 to UDP port 68. Because the DHCP client does not yet have an IPv4 address and has not determined the IPv4 addresses of any DHCP servers, the source IPv4 address for the DHCPDiscover broadcast is the unspecified address, 0.0.0.0, and the destination is the limited broadcast address, 255.255.255.255. The DHCPDiscover message contains the DHCP client’s media access control (MAC) address and computer name.

If a DHCP server is on the DHCP client's subnet, the server receives the broadcast DHCPDiscover message. If no DHCP server on the DHCP client’s subnet (a more typical configuration), a DHCP relay agent on the DHCP client’s subnet receives the broadcast DHCPDiscover message and relays it as a unicast DHCPDiscover message from the DHCP relay agent to one or more DHCP servers. Before forwarding the original DHCPDiscover message, the DHCP relay agent makes the following changes:

Increments the Hops field in the DHCP header of the DHCPDiscover message. The Hops field, which is separate from the Time to Live (TTL) field in the IPv4 header, indicates how many DHCP relay agents have handled this message. Typically, only one DHCP relay agent is located between any DHCP client and any DHCP server.
If the value of the Giaddr (Gateway IP Address) field in the DHCP header of the DHCPDiscover message is 0.0.0.0 (as set by the originating DHCP client), changes the value to the IPv4 address of the interface on which the DHCPDiscover message was received. The Giaddr field records the IPv4 address of an interface on the subnet of the originating DHCP client. The DHCP server uses the value of the Giaddr field to determine the address range, known as a scope, from which to allocate an IPv4 address to the DHCP client.
Changes the source IPv4 address of the DHCPDiscover message to an IPv4 address assigned to the DHCP relay agent.
Changes the destination IPv4 address of the DHCPDiscover message to the unicast IPv4 address of a DHCP server.

The DHCP relay agent sends the DHCPDiscover message as a unicast IPv4 packet rather than as an IPv4 and MAC-level broadcast. If the DHCP relay agent is configured with multiple DHCP servers, it sends each DHCP server a copy of the DHCPDiscover message.

Figure 6-3 shows the sending of the DHCPDiscover message by a DHCP relay agent that is configured with two DHCP servers.

Figure 6-3 Sending the DHCPDiscover message

The Selecting State

In the Initializing state, the DHCP client can select from the set of IPv4 address configurations that the DHCP servers offered. All DHCP servers that receive the DHCPDiscover message and that have a valid IPv4 address configuration for the DHCP client respond with a DHCPOffer message from UDP port 68 to UDP port 67. A DHCP server can receive the DHCPDiscover message either as a broadcast (because the DHCP server is on the same subnet as the DHCP client) or as a unicast from a DHCP relay agent.

The DHCP server uses the following process to determine the scope on the DHCP server from which an IPv4 address for the DHCP client is to be selected and included in the DHCPOffer message:

If the Giaddr field is set to 0.0.0.0, set the value of the Giaddr field to the IPv4 address of the interface on which the DHCPDiscover message was received.
For each scope on the DHCP server, perform a bit-wise logical AND of the value in the Giaddr field with the subnet mask of the scope. If the result matches the subnet prefix of the scope, the DHCP server allocates an IPv4 address from that scope. To obtain the subnet prefix of the scope, the DHCP server performs a bit-wise logical AND of the subnet mask of the scope with any address in the scope.

If the DHCPDiscover message was received as a broadcast, the DHCP server sends the DHCPOffer message to the DHCP client using the offered IPv4 address as the destination IPv4 address and the client's MAC address as the destination MAC address. If the DHCPDiscover message was received as a unicast, the DHCP server sends the DHCPOffer message to the DHCP relay agent. The DHCP relay agent uses the Giaddr value to determine the interface to use to forward the DHCPOffer message. The DHCP relay agent then forwards the DHCPOffer message to the client using the offered IPv4 address as the destination IPv4 address and the client's MAC address as the destination MAC address.

Figure 6-4 shows the sending of the DHCPOffer message.

Figure 6-4 Sending of DHCPOffer message

Note The discussion of how the DHCP server or DHCP relay agent sends DHCP messages to the DHCP client during the Selecting, Bound, and Rebinding states assumes that the Broadcast bit in the DHCP header of DHCP messages that the DHCP client sends is set to 0. The Broadcast bit indicates whether the DHCP client must receive responses to broadcast DHCPDiscover, DHCPRequest, and DHCPDecline messages as broadcasts, rather than as unicasts. The DHCP Client service in Windows Server 2003 and Windows XP allows unicast responses and therefore always sets the Broadcast bit to 0.

The DHCPOffer messages contain the DHCP client’s MAC address, an offered IPv4 address, appropriate subnet mask, a server identifier (the IPv4 address of the offering DHCP server), the length of the lease, and other configuration parameters. When a DHCP server sends a DHCPOffer message offering an IPv4 address, the DHCP server reserves the IPv4 address so that it will not be offered to another DHCP client.

The DHCP client selects the IPv4 address configuration of the first DHCPOffer message it receives. If the DHCP client does not receive any DHCPOffer messages, it continues to retry sending DHCPDiscover messages for up to one minute. After one minute, a DHCP client based on Windows Server 2003 or Windows XP configures an alternate configuration, either through APIPA or an alternate configuration that has been configured manually.

The Requesting State

In the Requesting state, the DHCP client requests a specific IP address configuration by broadcasting a DHCPRequest message. The client must use a broadcast because it does not yet have a confirmed IPv4 address configuration. Just as in the DHCPDiscover message, the DHCP client sends the DHCPRequest message from UDP port 67 to UDP port 68 using the source IPv4 address of 0.0.0.0 and the destination IPv4 address of 255.255.255.255.

If the DHCP client does not have a DHCP server on its subnet, a DHCP relay agent on its subnet receives the broadcast DHCPRequest message and relays it as a unicast DHCPRequest message from the DHCP relay agent to one or more DHCP servers.

The data in the DHCPRequest message varies in the following way, depending on how the requested IPv4 address was obtained:

If the IPv4 address configuration of the DHCP client was just obtained with a DHCPDiscover/DHCPOffer message exchange, the DHCP client includes the IPv4 address of the server from which it received the offer in the DHCPRequest message. This server identifier causes the specified DHCP server to respond to the request and all other DHCP servers to retract their DHCP offers to the client. These retractions make the IPv4 addresses that the other DHCP servers offered immediately available to the next DHCP client.
If the IPv4 address configuration of the client was previously known (for example, the computer was restarted and is trying to renew its lease on its previous address), the DHCP client does not include the IPv4 address of the server from which it received the IPv4 address configuration. This condition ensures that when restarting, the DHCP client can renew its IPv4 address configuration from any DHCP server.

Figure 6-5 shows the sending of the DHCPRequest message.

Figure 6-5 Sending the DHCPRequest message

The Bound State

In the Bound state, the DHCP client receives confirmation that DHCP server has allocated and reserved the offered IPv4 address configuration to the DHCP client. The DHCP server that leased the requested IPv4 address responds with either a successful acknowledgment (DHCPAck) or a negative acknowledgment (DHCPNak). The DHCP server sends the DHCPAck message from UDP port 68 to UDP port 67, and the message contains a lease period for the requested IPv4 address configuration as well as any additional configuration parameters.

If the DHCPRequest message was received as a broadcast, the DHCP server sends the DHCPAck message to the DHCP client using the offered IPv4 address as the destination IPv4 address and the client's MAC address as the destination MAC address. If the DHCPRequest was received as a unicast, the DHCP server sends the DHCPAck message to the DHCP relay agent. The DHCP relay agent uses the Giaddr value to determine the interface to use to forward the DHCPAck message. The DHCP relay agent then forwards the DHCPAck message to the DHCP client using the offered IPv4 address as the destination IPv4 address and the DHCP client's MAC address as the destination MAC address.

Figure 6-6 shows the sending of the DHCPAck message.

Figure 6-6 Sending the DHCPAck message

When the DHCP client receives the DHCPAck message, it enters the Bound state. The DHCP client completes the initialization of TCP/IP, which includes verifying that the IPv4 address is unique on the subnet. If the IPv4 address is unique, the DHCP client computer can use TCP/IP to communicate. If the IPv4 address is not unique, the DHCP client broadcasts a DHCPDecline message and returns to the Initializing state. The DHCP server receives the DHCPDecline message either as a broadcast or as a unicast through a DHCP relay agent. When the DHCP server receives the DHCPDecline message, it marks the offered IPv4 address as unusable.

A DHCP server sends a DHCPNak (DHCP negative acknowledgement) message if:

The client is trying to lease its previous IPv4 address and the IPv4 address is no longer available.
The IPv4 address is invalid because the client has been physically moved to a different subnet.

The DHCPNak message is forwarded to the DHCP client's subnet using the same method as the DHCPAck message. When the DHCP client receives a DHCPNak, it returns to the Initializing state.

The Renewing State

In the Renewing state, a DHCP client is attempting to renew the lease on its IPv4 address configuration by communicating directly with its DHCP server. By default, DHCP clients first try to renew their lease when 50 percent of the lease time has expired. To renew its lease, a DHCP client sends a unicast DHCPRequest message to the DHCP server from which it obtained the lease.

The DHCP server automatically renews the lease by responding with a DHCPAck message. This DHCPAck message contains the new lease and additional configuration parameters so that the DHCP client can update its settings. For example, the network administrator might have updated settings on the DHCP server since the lease was acquired or last renewed. When the DHCP client has renewed its lease, it returns to the Bound state.

Figure 6-7 shows the DHCP renewing process.

Figure 6-7 The DHCP renewing process

The Rebinding State

In the Rebinding state, a DHCP client is attempting to renew the lease on its IPv4 address configuration by communicating directly with any DHCP server. When 87.5 percent of the lease time has expired and the DHCP client has been unsuccessful in contacting its DHCP server to renew its lease, the DHCP client attempts to contact any available DHCP server by broadcasting DHCPRequest messages. Any DHCP server can respond with a DHCPAck message renewing the lease or a DHCPNak message denying the continued use of the IPv4 address configuration.

If the lease expires or the DHCP client receives a DHCPNak message, it must immediately discontinue using the IPv4 address configuration and return to the Initializing state. If the client loses its IPv4 address, communication over TCP/IP will stop until a different IPv4 address is assigned to the client. This condition will cause network errors for any applications that attempt to communicate using the invalid address.

Figure 6-8 shows the DHCP rebinding process.

Figure 6-8 The DHCP rebinding process

Restarting a Windows-based DHCP Client

The DHCP Client service in Windows XP and Windows Server 2003 uses these states when leasing an IPv4 address configuration from a DHCP server. However, when a Windows-based DHCP client is shut down, by default it does not release the IPv4 address configuration and return to the Initializing state. It does not send a DHCPRelease message and, from the perspective of the DHCP server, the client is still in the Bound state. When the Windows-based DHCP Client service is restarted, it enters the Requesting state and attempts to lease its previously allocated IPv4 address configuration through a broadcasted DHCPRequest message. The DHCPRequest is sent to the limited IPv4 broadcast address 255.255.255.255 and to the MAC-level broadcast address and contains the MAC address and the previously allocated IPv4 address of the DHCP client.

Note You can change the default behavior of a DHCP client running Windows XP or Windows Server 2003 so that the client sends a DHCPRelease message when it shuts down. To make this change, you use the Microsoft vendor-specific DHCP option named Release DHCP Lease on Shutdown.

Figure 6-9 shows the DHCP states for a Windows-based DHCP client

Figure 6-9 DHCP states for a Windows-based DHCP client

When a DHCP relay agent on the subnet receives the DHCPRequest message, it makes the following changes to the message before forwarding:

Increments the Hops field in the DHCP header.
Records the IPv4 address of the interface on which the DHCPRequest message was received in the Giaddr field.
Changes the source IPv4 address of the DHCPRequest message to an IPv4 address assigned to the DHCP relay agent.
Changes the destination IPv4 address to the IPv4 address of a DHCP server.

When the DHCP server receives the DHCPRequest message, it compares the subnet prefix of client's previously allocated IPv4 address to the subnet prefix of the IPv4 address stored in the Giaddr field and does the following:

If the two subnet prefixes are the same and the IPv4 address can be reallocated to the DHCP client, the DHCP server sends a DHCPAck to the DHCP relay agent. When the DHCP relay agent receives the DHCPAck, the agent re-addresses the message to the client's current IPv4 address and MAC address.
If the two subnet prefixes are the same and the IPv4 address cannot be reallocated to the DHCP client, the DHCP server sends a DHCPNak to the DHCP relay agent. When the DHCP relay agent receives the DHCPNak, it sends the message to the client's current IPv4 address and MAC address. At this point, the DHCP client goes into the Initializing state.
If the two subnet prefixes are not the same, the DHCP client has moved to a different subnet, and the DHCP server sends a DHCPNak to the DHCP relay agent. When the DHCP relay agent receives the DHCPNak, the agent sends the message to the client's current IPv4 address and MAC address. At this point, the DHCP client goes into the Initializing state.

The Windows DHCP Server Service

Before you install a Windows-based DHCP server, ask yourself these questions:

What IPv4 configuration options will DHCP clients obtain from a DHCP server (such as default gateway, DNS servers, a DNS domain name, or WINS servers)?

The IPv4 configuration options determine how you should configure the DHCP server and whether the options should be created for all clients in the entire network, clients on a specific subnet, or individual clients.
Will all computers become DHCP clients?

If not, consider that non-DHCP clients have static IPv4 addresses, and you might have to exclude those addresses from the scopes that you create on DHCP servers. If a specific DHCP client requires a specific IPv4 address, you must reserve the address.
Will a DHCP server supply IPv4 addresses to multiple subnets?

If so, each subnet must contain a DHCP relay agent. If a subnet does not have a DHCP relay agent, you must install a separate DHCP server on the subnet.
How many DHCP servers do you require?

To ensure fault tolerance for DHCP configuration, you should use at least two DHCP servers. You might need additional DHCP servers for branch offices of a large organization.

Installing the DHCP Server Service

To install the DHCP Server service on Windows Server 2003, do the following:

Click Start, click Control Panel, double-click Add or Remove Programs, and then click Add/Remove Windows Components.
Under Components, click Networking Services.
Click Details.
In Subcomponents of Networking Services, click Dynamic Host Configuration Protocol (DHCP), and then click OK.
Click Next. If prompted, type the full path to the Windows Server 2003 installation files, and then click Next.

The DHCP Server service starts automatically. The DHCP Server service must be running to communicate with DHCP clients.

The DHCP server cannot be a DHCP client. It must have a manually configured IPv4 address, subnet mask, and default gateway address on all of its LAN interfaces.

DHCP and Active Directory Integration

In Windows Server 2003, the DHCP Server service is integrated with Active Directory to provide authorization for DHCP servers. An unauthorized DHCP server on a network can disrupt network operations by allocating incorrect addresses or configuration options. A DHCP server that is a domain controller or a member of an Active Directory domain queries Active Directory for the list of authorized servers (identified by IPv4 address). If its own IPv4 address is not in the list of authorized DHCP servers, the DHCP Server service does not complete its startup sequence and automatically shuts down.

For a DHCP server that is not a member of the Active Directory domain, the DHCP Server service sends a broadcast DHCPInform message to request information about the root Active Directory domain in which other DHCP servers are installed and configured. Other DHCP servers on the network respond with a DHCPAck message, which contains information that the querying DHCP server uses to locate the Active Directory root domain. The starting DHCP server then queries Active Directory for a list of authorized DHCP servers and starts the DHCP Server service only if its own address is in the list.

BOOTP Support

The bootstrap protocol (BOOTP) is a host configuration protocol that was developed before DHCP to allow a diskless host computer to obtain an IPv4 address configuration, the name of a boot file, and the location of a Trivial File Transfer Protocol (TFTP) server from which the computer loads the boot file.

Windows Server 2003 supports BOOTP clients through the BOOTP Table folder in the console tree of the DHCP snap-in. The display of this folder is disabled by default, but you can enable it from the General tab in the properties of a DHCP server in the DHCP snap-in. After you enable the display of that folder, you can add BOOTP image entries specifying the location of boot files and TFTP servers for BOOTP clients from the BOOTP Table folder.

DHCP Server Service Configuration

The configuration of the DHCP Server service consists of a set of properties for the DHCP server, scopes, and DHCP options. This service is typically configured using the DHCP snap-in located in the Administrative Tools folder. You can also use netsh dhcp commands to configure local or remote DHCP servers.

Properties of the DHCP Server

To modify the properties of a DHCP server, right-click the name of the server in the console tree of the DHCP snap-in, and click Properties. A ServerName Properties dialog box should appear with the following tabs:

General

On the General tab, you can enable the automatic update of statistics in the server statistics window of the DHCP snap-in and specify how often the statistics are updated. You can also enable DHCP audit logging to record DHCP server activity in a file and enable the display of the BOOTP Table folder in the DHCP console tree.
DNS

On the DNS tab, you can specify the settings for DNS dynamic update. For more information about DHCP and DNS integration, see the "Dynamic Update and Secure Dynamic Update" section in Chapter 9, "Windows Support for DNS."
Advanced

On the Advanced tab, you can configure server conflict detection (the DHCP Server service attempts to ping each address it intends to offer before sending the DHCPOffer message); configure paths for the audit log, database, and backup database; and specify which connections (LAN interfaces) on which the DHCP Server service is listening for DHCP messages and credentials for DNS dynamic updates.

Figure 6-10 shows the properties dialog box for a DHCP server.

Figure 6-10 The properties dialog box for a DHCP server

DHCP Scopes

A DHCP scope is the consecutive range of possible IPv4 unicast addresses that DHCP clients on a subnet can use. Scopes typically define a single physical subnet on your network to which DHCP services are offered. Scopes are the primary way for the DHCP server to manage distribution and assignment of IPv4 addresses and any related configuration parameters to DHCP clients on the network.

The DHCP Server service in Windows Server 2003 also supports multicast scopes.

Configuring a DHCP Scope

After you have installed and started the DHCP Server service, your next step is to configure a scope. Every DHCP server requires at least one scope with a pool of IPv4 addresses available for leasing to DHCP clients. Typically, you create multiple scopes—one for each subnet for which the DHCP is offering addresses.

If a subnet contains manually configured TCP/IP nodes, you should exclude their IPv4 addresses from the scope. Otherwise, the DHCP server might allocate an address that is already in use on the subnet, causing problems with duplicate addresses.

To create a DHCP scope, do the following:

Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click DHCP.
In the console tree, click the DHCP server on which you want to configure a scope.
On the Action menu, click New scope.
Follow the instructions in the New Scope Wizard.

The New Scope Wizard guides you through naming the scope; specifying the address range, exclusions, and lease duration; configuring DHCP options (default gateway, DNS settings, WINS settings); and activating the scope. If you do not activate the scope from the New Scope Wizard, you can manually activate it by right-clicking the scope name in the console tree, and then clicking Activate.

Deploying Multiple DHCP Servers

To ensure that DHCP clients can lease IPv4 addresses even if a DHCP server becomes unavailable, you should create multiple scopes for each subnet and distribute them among the DHCP servers in the network. As a general rule, you should do the following for each subnet:

On a DHCP server that is designated the primary DHCP server for the subnet, create a scope containing approximately 80 percent of the IPv4 addresses available to DHCP clients.
On a DHCP server that is designated as the secondary DHCP server for the subnet, create a scope containing approximately 20 percent of the IPv4 addresses available to DHCP clients.

When the primary DHCP server for a subnet becomes unavailable, the secondary DHCP server can still service DHCP clients on the subnet.

Figure 6-11 shows a simplified example DHCP configuration.

Figure 6-11 An example of subnet address distribution on multiple DHCP servers

Server1 has a scope for the local subnet with an IPv4 address range of 131.107.4.20 through 131.107.4.160, and Server2 has a scope with an IPv4 address range of 131.107.3.20 through 131.107.3.160. Each server can lease IPv4 addresses to clients on its own subnet.

Additionally, each server has a scope containing a small range of IPv4 addresses for the other subnet. For example, Server1 has a scope for Subnet B with the IPv4 address range of 131.107.3.161 through 131.107.3.200. Server2 has a scope for Subnet A with the IPv4 address range of 131.107.4.161 through 131.107.4.200. If a client on Subnet A is unable to lease an address from Server1, it can lease an address for its subnet from Server2, and vice versa.

The primary DHCP server for a subnet does not have to be located on the subnet. In practice, most subnets do not contain a DHCP server, but they do contain a DHCP relay agent. For a large network in which the DHCP servers are located on network segments containing other servers, the primary DHCP server for a given subnet is the DHCP server that is topologically closest to the subnet and contains approximately 80 percent of the addresses for the subnet. The secondary DHCP server for a given subnet is the DHCP server that is topologically farther from the subnet than the primary DHCP server and contains approximately 20 percent of the addresses for the subnet.

Because DHCP servers do not share scope information, it is important that each scope contain a unique range of IPv4 addresses. If the scopes of different DHCP servers contain the same IPv4 addresses (known as overlapping scopes), multiple servers can lease the same IPv4 addresses to different DHCP clients on a subnet, causing problems with duplicate IPv4 addresses.

Superscopes

A superscope is an administrative grouping of scopes that you can use to support multiple logical IPv4 subnets on the same physical subnet. Superscopes contain a list of member scopes that can be activated together. You cannot use superscopes to configure other details about scope usage. For configuring most properties used within a superscope, you must configure individual properties of member scopes.

By using a superscope, you can support DHCP clients on locally attached or remote networks that have multiple logical subnets on one physical network segment (sometimes referred to as a multi-net).

To create a superscope, do the following:

Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click DHCP.
In the console tree, click the applicable DHCP server.
On the Action menu, click New superscope.
Follow the instructions in the New Superscope Wizard.

The New Superscope Wizard guides you through naming the superscope and selecting the set of previously created scopes to add to the superscope.

Options

Options are other TCP/IP configuration parameters that a DHCP server can assign when offering leases to DHCP clients. For example, commonly used options include IPv4 addresses for default gateways (routers), DNS servers, DNS domain names, and WINS servers. Options can apply to all the scopes configured on the DHCP server or only to a specific scope. Most options are predefined in RFC 2132, but you can use the DHCP snap-in to define and add custom option types if needed.

You can manage options at the following levels:

Server options

These options apply to all scopes defined on a DHCP server. Server options are available to all DHCP clients of the DHCP server. Server options are used when all clients on all subnets require the same configuration information. For example, you might want to configure all DHCP clients to use the same DNS domain name. Server options are always used, unless overridden by scope, class, or reservation options.
Scope options

These options apply to all DHCP clients that obtain a lease within a particular scope. For example, each subnet has a different IPv4 address as its default gateway address. Therefore, the option for assigning the default gateway must be a scope option. Scope options override global options for the same configuration parameter.
Class options

These options apply only to clients that are identified as members of a specified vendor or user class when obtaining a lease. For more information about vendor and user classes, see "DHCP Options Classes" in this chapter.
Reservation options

These options apply only to a single reserved client computer and require a reservation to be used in an active scope. Reservation options override server and scope options for the same configuration parameter. For more information about reservations, see "Client Reservations" in this chapter.

To configure a scope option:

Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click DHCP.
In the console tree, open the applicable DHCP server, open the applicable scope, and then click Scope Options.
On the Action menu, click Configure Options.
In Available Options, select the check box for the first option that you want to configure.
Under Data entry, type the information required for this option.
Repeat the steps 4-5 for any other options you want to specify, and then click OK.

You can also click the Advanced tab, and specify additional scope options to apply only to members of selected user or vendor classes.

Figure 6-12 shows an example of the configuration of the DNS Servers scope option.

Figure 6-12 An example of configuring the DNS Servers scope option

Even though a DHCP server running Windows Server 2003 can offer all the options in the options list, DHCP clients running Windows XP and Windows Server 2003 request only the options listed in Table 6-1 during the DHCP configuration process.

Option	Description
001 Subnet Mask	Specifies the subnet mask associated with the leased IPv4 address. The subnet mask is configured with a scope and does not need to be separately configured as an option.
003 Router	Specifies the IPv4 address of a host's default gateway.
006 DNS Servers	Specifies the IPv4 addresses of DNS servers.
015 DNS Domain Name	Specifies the connection-specific DNS domain suffix to be used by the DHCP client.
031 Perform Router Discovery	Specifies whether the DHCP client uses Internet Control Message Protocol (ICMP) router discovery as a host, as specified in RFC 1256.
033 Static Route	Specifies a set of classful IPv4 network destinations and their corresponding router IPv4 addresses that DHCP clients add to their IPv4 routing tables.
043 Vendor-specific Information	Specifies that vendor-specific options are requested.
044 WINS/NBNS Servers	Specifies the IPv4 addresses of WINS servers.
046 WINS/NBT Node Type	Specifies the type of network basic input/output system (NetBIOS) over TCP/IP name resolution to be used by the client.
047 NetBIOS Scope ID	Specifies the NetBIOS scope ID. NetBIOS over TCP/IP (NetBT) hosts will communicate only with other NetBT hosts that are using the same scope ID.
249 Classless Static Routes	Specifies a set of classless routes that are added to the IPv4 routing table of the DHCP client.

Table 6-1 DHCP options requested by a Windows-based DHCP client

Windows components can request additional DHCP options by using the DhcpRequestParams() function call. For more information, see How to Request Additional DHCP Options from a DHCP Server. DHCP clients that are not running Windows can request any DHCP option.

Client Reservations

You use a client reservation to ensure that a specified interface of a network node is always allocated the same IPv4 address. Some DHCP clients cannot change their IPv4 address configuration. For example, servers on a network that contains clients that are not WINS-enabled should always lease the same IPv4 address. Clients that are not WINS-enabled must use the Lmhosts file to resolve NetBIOS computer names of hosts on remote networks. If the IPv4 address of the server changes because it is not reserved, name resolution using Lmhosts will fail. Reserving an IPv4 address for the server ensures that its IPv4 address will remain the same.

To configure a client reservation:

Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click DHCP.
In the console tree, open the applicable DHCP server, open the applicable scope or superscope, and then click Reservations.
On the Action menu, click New Reservation.
In New Reservation, type the information required to complete the client reservation.
To add the client reservation to the scope, click Add.
Repeat steps 3-5 for any other client reservations that you want to add, and then click Close.

Figure 6-13 shows an example of configuring a reservation.

Figure 6-13 An example of configuring a reservation

The MAC address field is the most important entry in the reservation dialog box because DHCP clients send their MAC addresses in the DHCPDiscover and DHCPRequest messages. If this value is incorrectly typed, it will not match the value sent by the DHCP client. As a result, the DHCP server will assign the client any available IPv4 address in the scope instead of the IPv4 address reserved for the client. To obtain or verify a DHCP client’s MAC address, type ipconfig /all at the command prompt on the DHCP client.

Fault Tolerance for Client Reservations

To provide fault tolerance for client reservations, the reservation must exist on at least two DHCP servers. The client can receive its lease from any DHCP server and will be guaranteed the same IPv4 address. However, the only way to have the same client reservations on multiple DHCP servers is to have overlapping scopes. If any dynamic addresses are allocated from these overlapping scopes, addresses will conflict. Therefore, you should not use overlapping scopes unless all of the addresses in the overlap of the scopes are client reservations.

DHCP Options Classes

An options class is a way for you to further manage options provided to DHCP clients. When you add an options class to the DHCP server, it can provide DHCP clients of that class with class-specific option types for their configuration. DHCP client computers running Windows Server 2003 or Windows XP can also specify a class ID when they communicate with the server. To support earlier DHCP clients that do not support class IDs, you can configure the DHCP server with default classes. Options classes can be of two types: vendor classes and user classes.

Vendor Classes

DHCP clients can use vendor-defined options classes to identify the client's vendor type and configuration to the DHCP server when the client obtains a lease. For a client to identify its vendor class during the lease process, the client needs to include the Vendor Class ID option (option code 60) in the DHCPDiscover and DHCPRequest messages.

The vendor class identifier is a string of character data that DHCP servers interpret. Vendors can define specific vendor class identifiers to convey particular configuration or other identification information about a client. For example, the identifier might encode the client's hardware or software configuration. Most vendor types are derived from standard reserved hardware and operating system-type abbreviation codes listed in RFC 1700.

When a client specifies vendor options, the DHCP server performs the following additional steps to provide a lease to the client:

The server verifies whether the vendor class identified by the client request is also defined on the server.
If the vendor class is defined, the server verifies whether any additional DHCP options are configured for this class in the matching scope.

If the vendor class is not recognized, the server ignores the vendor class identified in the client request, and the server returns options allocated to the default vendor class, known as the DHCP Standard Options vendor class. If the scope contains options configured specifically for use with clients in this vendor-defined class, the server returns those options using the Vendor-specific option type (option code 43) in the DHCPAck message.

DHCP clients running Windows Server 2003 or Windows XP use the Microsoft Windows 2000 Options vendor class, which the DHCP Server service adds by default. In most cases, the default vendor class—DHCP Standard Options—provides a way to group any Windows-based DHCP clients or other DHCP clients that do not specify a vendor class ID. In some cases, you might define additional vendor classes for other DHCP clients, such as printers or some types of UNIX clients. When you add other vendor classes for these purposes, the vendor class identifier that you use when you configure the class at the server should match the identifier that the DHCP clients use.

User Classes

User classes allow DHCP clients to differentiate themselves by specifying what types of clients they are, such as a remote access client computer or desktop computer. For DHCP clients running Windows Server 2003 or Windows XP, you can define specific user class identifiers to convey information about a client's software configuration, its physical location in a building, or its user preferences. For example, an identifier can specify that DHCP clients are members of a user-defined class called "2nd floor, West," which needs a special set of router, DNS, and WINS server settings. An administrator can then configure the DHCP server to assign different option types depending on the type of client receiving the lease.

You can use user classes in the following ways:

DHCP client computers can identify themselves as part of a specific user class by including DHCP user class options when sending DHCP request messages to the DHCP server.
DHCP servers running Windows Server 2003 and the DHCP Server service can recognize and interpret the DHCP user class options from clients and provide additional options (or a modified set of DHCP options) based on the client's user class identity.

For example, shorter leases should be assigned to remote access clients who connect to the network over phone lines or the Internet. Different desktop clients on the same subnet might require special settings, such as WINS and DNS server settings.

If the client specifies no user-defined option classes, the server assigns that client default settings (such as server options or scope options).

You add vendor or user classes by right-clicking the DHCP server name in the DHCP snap-in and then clicking either Define Vendor Classes or Define User Classes. After you have added the classes, you configure user and vendor class options on the Advanced tab of the properties of a scope option. Figure 6-14 shows an example.

Figure 6-14 Configuring vendor and user classes

See "Setting and Displaying the Class ID" in this chapter for information about configuring the user class ID on computers running Windows Server 2003 or Windows XP.

The DHCP Relay Agent

The Routing and Remote Access service in Windows Server 2003 includes the DHCP Relay Agent, a routing protocol component that can act as an RFC 1542-compliant DHCP relay agent (also known as a BOOTP relay agent).

Installing the DHCP Relay Agent

Depending on your choices in the Routing and Remote Access Server Setup Wizard, you might have already installed the DHCP Relay Agent routing protocol component. If you must install and enable the DHCP Relay Agent, do the following:

Click Start, click Control Panel, double-click Administrative Tools, and then double-click Routing and Remote Access.
In the console tree of the Routing and Remote Access snap-in, double-click the server name, and then click IP Routing.
Right-click General, and then click New Routing Protocol.
In the Select Routing Protocol dialog box, click DHCP Relay Agent, and then click OK.
In the console tree, right-click DHCP Relay Agent, and then click Properties.
In the DHCP Relay Agent Properties dialog box, add the list of IPv4 addresses that correspond to the DHCP servers on your network to which this computer will forward DHCPDiscover, DHCPRequest, DHCPDecline, and DHCPInform messages.

Figure 6-15 shows an example of the DHCP Relay Agent Properties dialog box.

Figure 6-15 An example of the DHCP Relay Agent Properties dialog box

After you have installed the DHCP Relay Agent and configured the list of DHCP servers, you must enable the DHCP Relay Agent on the appropriate interfaces. To enable the DHCP Relay Agent on an additional interface, do the following:

In the console tree of the Routing and Remote Access snap-in, double-click the server name, and then double-click IP Routing.
Right-click DHCP Relay Agent, and then click New Interface.
Click the interface that you want to add, and then click OK.
In the DHCP Relay Properties dialog box, on the General tab, verify that the Relay DHCP packets check box is selected.
If needed, in Hop-count threshold and Boot threshold (seconds), click the arrows to modify the thresholds as needed.
Click OK.

Figure 6-16 shows an example of the DHCP Relay Properties dialog box for an interface.

Figure 6-16 An example of the DHCP Relay Properties dialog box for an interface

The Hop count threshold field is the maximum number of DHCP relay agents that can forward a DHCP message before this DHCP relay agent receives it. When a DHCP relay agent receives a DHCPDiscover, DHCPRequest, or DHCPDecline message, it checks the value of the Hops field in the DHCP header of the message. If the value in the Hops field exceeds the value in the hop count threshold, the DHCP relay agent silently discards the message. If not, the DHCP relay agent increments the value of the Hops field before forwarding the message.

The Boot threshold (seconds) field is the amount of time that the DHCP relay agent waits before it forwards broadcast DHCP request messages. This option is useful when you want a DHCP server on the same subnet as the DHCP client to respond first. If the local DHCP server does not respond, you want the DHCP relay agent to forward the messages to a remote DHCP server.

Address Autoconfiguration for IPv6

A highly useful feature of IPv6 is its ability to perform address autoconfiguration (specified in RFC 2462). Using address autoconfiguration, an IPv6 host can automatically configure itself without using an address configuration protocol, such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6). By default, an IPv6 host can configure a link-local address for each interface. By using router discovery, a host can also determine the addresses of routers, additional addresses, and other configuration parameters. The addresses configured using router discovery are known as stateless addresses. For stateless addresses, the router does not record which IPv6 hosts are using which addresses. The Router Advertisement message indicates whether a stateful address configuration protocol should be used.

Autoconfigured Address States

Autoconfigured addresses are in one or more of the following states:

Tentative

The address is in the process of being verified as unique. Verification occurs through duplicate address detection.
Valid

An address from which unicast traffic can be sent and received. The valid state covers both the preferred and deprecated states. The Router Advertisement message includes the amount of time that an address remains in the valid state. The valid lifetime must be greater than or equal to the preferred lifetime.
- Preferred
  
  An address for which uniqueness has been verified. A node can send and receive unicast traffic to and from a preferred address. The Router Advertisement message includes the period of time that an address can remain in the tentative and preferred states.
- Deprecated
  
  An address that is still valid but whose use is discouraged for new communication. Existing communication sessions can continue to use a deprecated address. A node can send and receive unicast traffic to and from a deprecated address.
Invalid

An address for which a node can no longer send or receive unicast traffic. An address enters the invalid state when the valid lifetime expires.

Figure 6-17 shows the relationship between the states of an autoconfigured address and the preferred and valid lifetimes.

Figure 6-17 States of an autoconfigured IPv6 address

With the exception of link-local addresses, address autoconfiguration is specified only for hosts. You must manually configure addresses and other parameters on routers.

Types of Autoconfiguration

There are three types of autoconfiguration:

Stateless

Address configuration is based on the receipt of Router Advertisement messages. These messages include stateless address prefixes and require hosts not to use a stateful address configuration protocol.
Stateful

Configuration is based on the use of a stateful address configuration protocol, such as DHCPv6, to obtain addresses and other configuration options. A host uses stateful address configuration when it receives Router Advertisement messages that do not include address prefixes and that require hosts to use a stateful address configuration protocol. A host will also use a stateful address configuration protocol when no routers are present on the local link.
Both

Configuration is based on receipt of Router Advertisement messages. These messages include stateless address prefixes and require hosts to use a stateful address configuration protocol.

For all autoconfiguration types, a link-local address is always configured.

Autoconfiguration Process

The address autoconfiguration process for an IPv6 node occurs as follows:

A tentative link-local address is derived from the link-local prefix of FE80::/64 and the 64-bit interface identifier.
Duplicate address detection is performed to verify the uniqueness of the tentative link-local address.

If duplicate address detection fails, you must configure the node manually.

If duplicate address detection succeeds, the tentative link-local address is assumed to be unique and valid. The link-local address is initialized for the interface.

For an IPv6 host, address autoconfiguration continues as follows:

The host sends a Router Solicitation message.
If the host receives no Router Advertisement messages, it uses a stateful address configuration protocol to obtain addresses and other configuration parameters. The IPv6 protocol for Windows Server 2003, Windows XP with Service Pack 1 (SP1), and Windows XP with Service Pack 2 (SP2) does not support the use of a stateful address configuration protocol, such as DHCPv6.
If the host receives a Router Advertisement message, the host is configured with the configuration information that the message includes.
For each stateless address prefix that is included:

The address prefix and the appropriate 64-bit interface identifier are used to derive a tentative address.
- Duplicate address detection verifies the uniqueness of the tentative address.
- If the tentative address is in use, the address is not initialized for the interface.
- If the tentative address is not in use, the address is initialized. This initialization includes setting the valid and preferred lifetimes based on information in the Router Advertisement message.
If specified in the Router Advertisement message, the host uses a stateful address configuration protocol to obtain additional addresses or configuration parameters.

Using the Ipconfig Tool

You use the Ipconfig tool to display a computer’s TCP/IP configuration and to manage an IPv4 address configuration that was allocated using DHCP.

Verifying the IP Configuration

To display basic information about the TCP/IP configuration of a computer that is running Windows Server 2003 or Windows XP, type ipconfig at the command prompt. The basic TCP/IP configuration information includes the following for each interface:

Connection-specific DNS suffix
IP addresses (IPv4 and IPv6)
Subnet mask (for IPv4 addresses)
Default gateway

To display detailed information about the TCP/IP configuration of a computer that is running Windows Server 2003 or Windows XP, type ipconfig /all at the command prompt.

The detailed TCP/IP configuration information includes the following additional items for the computer:

The host name
The primary DNS suffix
The NetBIOS node type
Whether IP routing is enabled
Whether the WINS proxy is enabled
The DNS suffix search list

The detailed TCP/IP configuration information also includes the following additional items for each interface:

Description of the network adapter
MAC address of the network adapter
Whether DHCP is enabled
Whether autoconfiguration (APIPA) is enabled
The IPv4 address of the DHCP server that allocated the IPv4 address of this interface
The IPv4 addresses of the primary and secondary WINS servers
For an IPv4 address that was allocated using DHCP, when the lease was obtained and when the lease expires

Renewing a Lease

To renew a lease on an IPv4 address that was allocated using DHCP, type ipconfig /renew at the command prompt. The /renew parameter causes the DHCP Client service to send a DHCPRequest message to the DHCP server to get updated options and a new lease time. If the DHCP server is unavailable, the client continues to use the current configuration.

Releasing a Lease

To release the current IPv4 address configuration, type ipconfig /release at the command prompt. The /release parameter causes the DHCP Client service to send a DHCPRelease message to the DHCP server. This can be useful when the client is moving to a different network and will not need the previous lease. After you issue this command, the interfaces that previously had IPv4 address configurations allocated using DHCP are configured with the IPv4 unspecified address of 0.0.0.0, and TCP/IP communications using that interface stops.

By default, DHCP clients running Windows do not initiate DHCPRelease messages when they shut down. If a client remains shut down for the length of its lease (and the lease is not renewed), the DHCP server can assign that client’s IPv4 address to a different client after the lease expires. By not sending a DHCPRelease message, the client is more likely to receive the same IPv4 address during initialization.

Setting and Displaying the Class ID

To set the user class ID on a computer running Windows Server 2003 or Windows XP, type ipconfig /setclassid Adapter ClassID at the command prompt, in which Adapter is the name of the interface in Network Connections and ClassID is the class ID. To remove the class ID from an interface, omit the ClassID parameter.

To display the user class ID, type ipconfig /showclassid Adapter at the command prompt.

Chapter Summary

The chapter includes the following pieces of key information:

DHCP is a TCP/IP standard described in RFCs 2131 and 2132, and it allows TPC/IP hosts to automatically receive an IPv4 address and other configuration parameters (such as a subnet mask, default gateway, and others) from a centrally administered DHCP server. Using DHCP eliminates the administrative and technical support problems associated with users who manually configure their IPv4 address configurations.
DHCP clients exchange a set of messages with a DHCP server to discover the set of DHCP servers, obtain a set of offered IPv4 address configurations, select a specific IPv4 address configuration, and receive an acknowledgement. DHCP relay agents facilitate DHCP message exchanges between DHCP clients and DHCP servers that are located on different subnets.
You can install the DHCP Server service in Windows Server 2003 as an optional networking component, and you can configure server properties, scopes and superscopes, options, and client reservations.
You can install and configure the DHCP Relay Agent in Windows Server 2003 as a routing protocol component of the Routing and Remote Access service.
Address autoconfiguration for IPv6 is done through the router discovery process, in which IPv6 nodes on a subnet use Router Solicitation and Router Advertisement messages to automatically configure IPv6 addresses and other configuration options.
You can use the Ipconfig tool to view a computer’s current IP configuration and to manage the IPv4 address configuration that was allocated using DHCP.

For additional resources about DHCP in Windows Server 2003 and Windows XP, see the Microsoft DHCP Web page.

Chapter Glossary

address autoconfiguration – The process of automatically configuring IPv6 addresses on an interface. See also stateless autoconfiguration and stateful autoconfiguration.

BOOTP – See bootstrap protocol (BOOTP).

bootstrap protocol (BOOTP) – A protocol that is defined in RFCs 951 and 1542 and that is used primarily on TCP/IP networks to configure diskless workstations.

deprecated state – The state of an autoconfigured IPv6 address in which the address is valid but its use is discouraged for new communication.

DHCP – See Dynamic Host Configuration Protocol (DHCP)

DHCP client – Any network node that supports the ability to communicate with a DHCP server to obtain a leased IPv4 configuration and related optional parameters information.

DHCP relay agent – An agent program or component that is responsible for relaying DHCP and BOOTP messages between a DHCP server and a DHCP client. A DHCP relay agent supports DHCP/BOOTP message relay as defined in RFC 1542. A DHCP relay agent can run on a router or a host computer.

DHCP server – A computer that offers dynamic configuration of IPv4 addresses and related information to DHCP-enabled clients.

Dynamic Host Configuration Protocol (DHCP) – A TCP/IP standard that offers dynamic leased configuration of host IPv4 addresses and other configuration parameters to DHCP clients. DHCP provides safe, reliable, and simple TCP/IP network configuration, prevents address conflicts, and helps conserve the use of client IPv4 addresses on the network.

exclusion range – A small range of one or more IPv4 addresses within a DHCP scope that are excluded for allocation to DHCP clients. Exclusion ranges ensure that DHCP servers do not offer specific addresses within a scope to DHCP clients.

invalid state – The state of an autoconfigured IPv6 address in which it can no longer be used to send or receive unicast traffic. An IPv6 address enters the invalid state when its valid lifetime expires.

lease – The length of time for which a DHCP client can use a dynamically assigned IPv4 address configuration. Before the lease time expires, the client must either renew or obtain a new lease with DHCP.

option – An address configuration parameter that a DHCP server assigns to clients. Most DHCP options are predefined, based on optional parameters defined in RFC 2132, although vendors or users can add extended options.

preferred lifetime – The amount of time in which a unicast IPv6 address configured through stateless address autoconfiguration remains in the preferred state.

preferred state – The state of an autoconfigured IPv6 address for which the address is valid, its uniqueness has been verified, and it can be used for unlimited communications.

reservation – A specific IPv4 address that is within a scope and that has been permanently reserved for use by a specific DHCP client. Client reservations are based on a unique client device identifier (typically its MAC address)

router discovery – An IPv6 Neighbor Discovery process in which a host discovers the routers on an attached link.

scope – A range of IPv4 addresses that are available to be leased or assigned to DHCP clients by the DHCP service.

stateful address configuration – The use of a stateful IPv6 address configuration protocol, such as DHCPv6, to configure IPv6 addresses and configuration parameters.

stateless address configuration – The use of Router Solicitation and Router Advertisement messages to automatically configure IPv6 addresses and configuration parameters.

superscope – An administrative grouping feature that supports a DHCP server's ability to use more than scope for a physical network. Each superscope can contain one or more member scopes.

tentative address – A unicast IPv6 address whose uniqueness has not yet been verified.

tentative state – The state of an autoconfigured IPv6 address in which uniqueness has not yet been verified.

user class – An administrative feature that allows DHCP clients to be grouped logically according to a shared or common need. For example, you can define a user class and use it to allow similar DHCP leased configuration for all client computers of a specific type or in a specific building or site location.

valid state – The state of an autoconfigured IPv6 address for which the address can be used for sending and receiving unicast traffic. The valid state includes both the preferred and deprecated states.

vendor class – An administrative feature that allows DHCP clients to be identified and allocated addresses and options according to their vendor and hardware configuration type. For example, assigning a vendor class to a set of printers allows them to be managed as a single unit so they could all obtain a custom set of DHCP options.

Compartilhar via