Planning a DHCP Strategy
As you learned earlier in the chapter, DHCP servers are required to implement dynamic IP addressing. The following section looks at some of the important topics you need to consider when planning a DHCP strategy.
DHCP Server Placement
Before you install the DHCP service, you need to identify where on the network the DHCP servers will be placed. Consider the following points when determining where you should place the DHCP servers:
- If there are slow network connections, consider placing DHCP servers locally. This will minimize traffic on the slow connections.
- Place DHCP servers as close as possible to DHCP clients to optimize response times.
- Consider using more than one DHCP server for fault tolerance.
- If there are multiple subnets, place DHCP servers on those subnets with the highest number of DHCP clients or those with frequent lease renewals.
DHCP Relay Agent
When a DHCP client request for an IP address hits a non-RFC-1542–compliant router (meaning that the DHCPDISCOVER broadcast message can't be forwarded off the subnet), it fails to receive a response because the DHCP server never receives the DHCPDISCOVER broadcast message, and the client system configures itself with an APIPA address.
If a DHCP Relay Agent is in use on the subnet, it receives the DHCPDISCOVER broadcast message and forwards (routes) the message off the subnet to the DHCP server. Subsequently, when the DHCP server responds with an address and the DHCP client selects the IP address, the client responds with a DHCPREQUEST broadcast message that includes the IP address of the server whose offer was accepted. Again, this DHCPREQUEST broadcast message does not get out of this subnet unless a DHCP Relay Agent in use on the subnet can receive the DHCPREQUEST broadcast message and forward (route) the message off the subnet to the DHCP server. Since the DHCPREQUEST is a broadcast, it will be blocked by routers that filter out broadcasts as a matter of their function being a layer 3 device. Thus, to allow a DHCP client to communicate with a DHCP server in a different subnet, a DHCP relay agent must be used.
DHCP servers should be located on at least one subnet on a LAN in a routed network. When the server needs to support clients on remote subnets separated by routers, the router should be RFC 1542–compliant, or a DHCP Relay Agent should be used to support forwarding DHCP traffic between the subnets.
When your network design allows for more than one DHCP server on the same subnet, the scope should be divided equally between them. If the DHCP servers are on separate subnets, the 80/20 rule should be deployed. With the 80/20 rule, the local DHCP server is configured with 80% of the IP addresses within the scope. The remote DHCP server is configured with the remaining 20%. This will allow client computers to continue to obtain valid IP addresses even if the local DHCP server stops responding. You need to make sure that the relay agent is enabled on your router for this configuration to work.
Centralized Versus Decentralized
Where DHCP servers are placed on the network depends on whether you require a centralized or decentralized DHCP infrastructure. With a centralized structure, the DHCP servers are placed in a central location. In a subnetted network, this requires DHCP Relay Agents or routers that are BOOTP enabled. One of the disadvantages to this model is that it can end up increasing network traffic on slow network connections.
With a decentralized structure, DHCP servers are placed on each subnet. This can reduce network traffic on slow network connections. However, it can increase costs because additional DHCP servers are needed.
You can also implement a combination of both infrastructures. After you define the physical characteristics of the network, you can identify those subnets that require a DHCP server. For example, a subnet with few DHCP clients might not require a DHCP server to be placed locally.
In some instances, a workstation on the network requires a permanent IP address, but you still want that workstation to be a DHCP client. With a client reservation, the workstation can still be DHCP enabled, but the DHCP server always assigns the client the same IP address. The client reservation is based on the MAC address.
In terms of administration, the client network configuration settings remain the same, IP addressing remains centralized, and the clients can still be assigned optional parameters through the DHCP server.
After a scope has been created, you can configure several DHCP options. The options can be configured at one of the following four levels:
Options configured at the server level are applied to all DHCP clients, regardless of the subnet on which they reside. Any options that should be applied to all DHCP clients should be configured at this level. For example, to configure all clients on the network to use the same DNS server, you can configure the option at the server level. Keep in mind that when you are configuring scope options, any options configured at the scope or client levels override those configured at the server level. To configure server-level options, right-click the Server Options container listed under the DHCP server and select Set Predefined Options from the menu.
If you want to configure DHCP options so that they apply only to DHCP clients on a specific subnet, configure the options at the scope level. For example, the IP address of the default gateway for a subnet should be configured at the scope level. Configuring scope-level options can be done by right-clicking the Scope Options container and selecting Configure Options from the menu.
Finally, if you want to apply DHCP options to only a specific DHCP client, you can configure the options at the client level. You can configure options at this level only for clients that have a client reservation, meaning that they are DHCP clients but always lease the same IP address. Any option that you configure at this level overrides any configured at the server and scope levels. To configure a client-level option, right-click the client reservation and select Configure Options.
Windows Server 2003 also allows DHCP options to be applied to groups of users or workstations with similar needs. User-class options can be used to assign options to DHCP clients that have common needs for similar DHCP options configurations. For example, a user class can be used to configure options for mobile users. Vendor-class options can be used to assign DHCP options on the basis of vendor information. For example, specific options can be assigned to clients running a specific version of Windows.
Now that you're familiar with how DHCP options can be applied, let's take a look at the different DHCP options that can be assigned to clients. As previously mentioned, a DHCP server can assign parameters other than just an IP address and subnet mask to a DHCP client. A number of different options can be configured. To access the Server Options dialog box, highlight Server Options in the left pane of the DHCP management console and select Configure Options from the Action menu.
The following list provides a description of the commonly used DHCP options:
- 006 DNS Servers—Specifies the IP address of the DNS servers available to clients on the network.
- 015 DNS Domain Name—Specifies the DNS domain name used for client resolutions.
- 003 Router—Specifies the IP address of the router or default gateway.
- 044 WINS/NBNS Servers—Specifies the IP address of the WINS servers on the network available to clients.
- 046 WINS/NBT Node Type—Specifies the name resolution type. The available options include 1 = B-node (broadcast), 2 = P-node (peer), 4 = M-node (mixed), and 8 = H-node (hybrid).
- 240 Classless Static Routes—Specifies a list of static routes, including the destination network IP address, the subnet mask, and the router that is responsible for forwarding messages to that network.
Most of the options outlined in the preceding list can also be configured locally on the client. By doing so, any options configured on the DHCP server will be overwritten by those configured locally. If you are using DHCP, however, it would not make sense to configure the options locally as well, especially in terms of administrative overhead.
One of the ways that you can secure a DHCP implementation is to implement only Active Directory authorization. This would require all DHCP servers to be running Windows 2000 or later and be a member of an Active Directory domain. That way, when a DHCP server starts, it requests the server authorization list. If the DHCP server is not in the list of authorized servers, the DHCP service will fail to start. In order to authorize a DHCP server, your user account must be a member of the Enterprise Admins group.
Another way that you can secure your DHCP servers is to follow the principal of least privilege. Windows Server 2003 includes two built groups called the DHCP Users and the DHCP Administrators group. Members of the DHCP Users group have read-only access to the DHCP server while DHCP Administrators have full access. By placing users in the DHCP Users group, you can prevent unauthorized changes from being made to the server.
Each DHCP scope is configured with a lease duration. This specifies how long a DHCP client can use an IP address before it must be renewed by a DHCP server. By default, this value is set to eight days. However, you might want to change this depending on the number of IP addresses available as compared to the number of DHCP clients.
The lease duration can be customized to meet the requirements of your network. If the number of IP addresses exceeds the number of DHCP clients on the network, you can configure a longer lease duration. However, if the number of IP addresses available in the scope is comparable to the number of DHCP-enabled clients, you should configure a shorter lease duration. Also, if your network consists of a number of mobile users who move between subnets, consider creating a shorter lease time. By shortening the lease duration, you might also see a slight increase in network traffic because IP addresses are renewed at a more frequent interval.