Dynamic Host Configuration Protocol for Windows 2000

The Microsoft Windows 2000 Server network operating system includes an enhanced implementation of Dynamic Host Configuration Protocol (DHCP). This includes integration of DHCP with domain name system (DNS), enhanced monitoring and statistical reporting for DHCP servers, new vendor-specific options and user-class support, multicast address allocation, and rogue DHCP server detection. Also included is a discussion of Windows Clustering, a part of Windows 2000 Advanced Server. DHCP for Windows 2000 is open and based on industry standards, supporting Requests for Comments (RFCs) 2131 and 2132.

On This Page

Introduction
New for DHCP in Windows 2000
DHCP Overview
DHCP Deployment
Best Practices
Future
Summary
Appendix A: Predefined Options for DHCP CLients
Appendix B: Windows NT 4.0 Server Performance Measurement

Introduction

The Microsoft® Windows® 2000 Server network operating system builds on the longstanding Microsoft support for Dynamic Host Configuration Protocol (DHCP), an open, industry standard that reduces the complexity of administering networks based on TCP/IP. Each host computer connected to a TCP/IP network must be assigned a unique IP address. DHCP frees network administrators from having to configure all of the computers by hand.

TCP/IP is the global network protocol of choice, especially for corporate intranets adopting Internet technology. However, configuring and administering TCP/IP network clients have traditionally been time-consuming and costly. This is why Microsoft, as a member of the Internet Engineering Task Force (IETF), was an early advocate for having dynamic IP addressing technology and worked closely with other IETF members to create the DHCP solution.

DHCP is open and standards-based, as defined by IETF Requests for Comments (RFCs) 2131 and 2132. DHCP can automatically configure a host while it is booting on a TCP/IP network, as well as change settings while the host is attached. This lets all available IP addresses be stored in a central database along with associated configuration information, such as the subnet mask, gateways, and address of DNS servers.

DHCP makes life easier for network administrators, and the larger the network, the greater the benefit. Without dynamic address assignment, clients have to be configured one by one. IP addresses must be managed to avoid duplicate use. Changes must be applied to clients by hand. Configuration information is not centralized; and it is difficult to get a view of all client configurations.

In contrast, DHCP provides benefits including the following:

• DHCP is based on open IETF standards.

• Dynamic assignment of IP addresses allows address reuse through leases.

• Automatic pushdown of configurations to clients allows configuration changes to be applied transparently.

For Windows 2000 Server, the Microsoft DHCP server has been enhanced with powerful new features, including:

• Integration of DHCP with DNS.

• Enhanced monitoring and statistical reporting for DHCP servers.

• New vendor-specific and class ID option support.

• Multicast address allocation.

• Rogue DHCP server detection.

• Windows Clustering for high availability (after IETF release of the server-to-server communications protocol).

• Improved DHCP Manager.

These features, together with the robust functionality inherited from previous versions of Microsoft DHCP Server, make it a compelling solution to the networking needs of corporations today.

New for DHCP in Windows 2000

Microsoft Windows 2000 Server DHCP has been enhanced to make DHCP easier to deploy and manage. New features include:

• Integration of DHCP with DNS.

• Enhanced monitoring and statistical reporting for DHCP servers.

• New DHCP vendor-specific and class ID option support.

• Multicast address allocation.

• Rogue DHCP Server detection.

• Windows Clustering.

• Improved DHCP Manager.

• Automatic client configuration.

Integration of DHCP with DNS

Domain name system (DNS) servers provide name resolution for network resources and are closely related to DHCP services. For Windows 2000, DHCP servers and DHCP clients may register with DNS. Standards for managing DHCP and DNS interactions are still being developed by the IETF, and Microsoft is committed to supporting such standards as they are completed.

Taking a Closer Look at DHCP-DNS Integration

Details related to integrating dynamic DNS and DHCP services in Windows 2000 Server are not finalized, and Microsoft is reviewing how to implement DHCP/DNS integration for Windows 2000 Server. The specifications of the proposed implementation of DHCP-DNS interaction are described in a draft document (https://www.watersprings.org/pub/id/draft-ietf-dhc-dhcp-dns-08.txt), although this document may not fully describe the final implementation of DHCP/DNS interaction.

This IETF draft specifies how a DHCP server may register and update pointer (PTR) and address (A) resource records on behalf of its DHCP-enabled clients. It also specifies how to assign an additional DHCP option code (option code 81) that enables the return of a client's fully qualified domain name (FQDN) to the DHCP server. If implemented, this option is then interpreted by the DHCP server, which can then initiate further interaction and updating by using dynamic DNS (DDNS) to modify an individual host's resource records with a dynamic DNS server.

The ability to register both A and PTR type records lets a DHCP server act as a proxy for clients, such as the Microsoft Windows® 9x operating system and Windows NT 4.0, for the purpose of DDNS registration. The DHCP server can differentiate between Windows 2000 Professional and other clients. This DHCP option permits the DHCP server the following possible interactions for processing DNS information on behalf of DHCP clients:

• The DHCP server always registers the DHCP client for both the forward (A-type records) and reverse lookups (PTR-type records) with DNS.

• The DHCP server never registers the name-to-address (A-type records) for DHCP clients.

• The DHCP server registers the DHCP client for both forward (A-type records) and reverse lookups (PTR-type records) only when requested to by the client.

DHCP and static DNS service are not compatible for keeping name-to-address mapping information synchronized. This may cause problems with using DHCP and DNS together on a network if older, static DNS servers are employed, which are incapable of interacting dynamically when DHCP client configurations change.

To avoid failed DNS lookups for DHCP-registered clients where static DNS service is in effect, the following workarounds may be performed:

• If WINS servers are used on a network, enable WINS lookup for DHCP clients that use NetBIOS.

• Assign IP address reservations with an infinite lease duration for DHCP clients that use DNS only and do not support NetBIOS.

• Wherever possible, upgrade or replace older static DNS servers with DNS servers supporting dynamic DNS service. Dynamic DNS service is supported by the Microsoft DNS server included in Windows 2000 Server.

Enhanced Monitoring and Statistical Reporting for DHCP Servers

Enhanced monitoring and statistical reporting has been added to the DHCP server for Windows 2000. This new feature provides notification when IP addresses are running below a user-defined threshold. For example, an alert could be triggered when 90 percent of IP addresses assigned for a particular scope have been assigned. A second alert can be triggered when the pool of IP addresses is exhausted. To alert network managers, the icon is changed to yellow on the remaining addresses falling below the defined level. The icon is changed to red if the addresses is completely depleted.

The DHCP manager, which supports Simple Network Management Protocol (SNMP) and Management Information Bases (MIBs), provides graphical display of statistical data. This helps administrators monitor system status, such as the number of available versus depleted addresses, or the number of leases being processed per second. Additional statistical information includes the number of messages and offers processed, as well as the number of requests, acknowledgements, declines, negative status acknowledgment messages (Nacks), and releases received.

Also viewable is the total number of scopes and addresses on the server, the number used, and the number available. These statistics can be provided for a particular scope, or at the server level, which shows the aggregate of all scopes managed by that server.

New Vendor-specific Options and User Class Support

DHCP server for Windows 2000 provides the powerful functionality of allowing vendor-specific options to be defined, as an alternative to the potentially lengthy process of obtaining IETF approval for a new standard option. These vendor classes are defined by specific vendors and are triggered by data bits that determine whether a given option class is standard or vendor-specific. Once identified as vendor-specific, DHCP looks up the configuration as specified for the specific vendor. This feature enables compelling custom applications for enterprise networks to be introduced quickly. Equipment from multiple vendors on a network can also use different option numbers for different functions. The vendor class and vendor options are described in RFC 2132.

User Class Support

Today, all DHCP clients are treated equally, and the server is unaware of the specific type of clients. This means that the configuration issued by the server must be one that can be common to any DHCP client. An address can be assigned from a scope, along with the options available within that scope.

User classes allow DHCP clients to differentiate themselves by specifying what type of client they are, such as a desktop or laptop, for example. An administrator can then configure the DHCP server to assign different options, depending on the type of client receiving them. For example, shorter leases could be assigned to laptop clients. Desktop clients on the same network may require special settings, such as computer-aided design (CAD) platforms. These variations could include lease length, WINS and DNS settings, and all others allowed by DHCP options. This feature gives administrators greater flexibility in configuring clients. If client class options are unused, default settings are assigned.

Multicast Address Allocation

The Microsoft DHCP server has been extended to allow the assignment of multicast addresses, in addition to unicast addresses. A proposed IETF standard defines multicast address allocation. The proposed standard benefits network administrators by allowing multicast addresses to be assigned in the same fashion as unicast addresses, allowing complete utilization of the existing infrastructure.

Typical applications for multicast are conferencing or audio, which usually require users to specially configure multicast addresses. Unlike IP broadcasts, which must be readable by all computers on the network, a multicast address is a group of computers, using the concept of a group membership to identify those to whom the message is to be sent.

The multicast address allocation feature has two parts. The server side implementation to hand out multicast addresses and the client side APIs that applications can use to request, renew, and release multicast addresses. To use this feature, the administrator first configures the multicast scopes and the corresponding multicast IP ranges on the server through a snap-in. The multicast addresses are then managed like normal IP addresses. The client can call the APIs to request a multicast address from a scope. The underlying implementation uses DHCP protocol–style packet formats between client and the server.

Unauthorized DHCP Server Detection

The Microsoft DHCP server for Windows 2000 is designed to prevent unauthorized DHCP servers from creating address assignment conflicts. This solves problems that could otherwise occur if naïve users created unauthorized DHCP servers that could assign improper or unintended IP addresses to clients elsewhere on the network. For example, a user could create what was intended to be a local DHCP server, using non-unique Net 10 addresses that could lease the addresses to unintended clients requesting addresses from elsewhere on the network.

This is one reason to keep the number of DHCP servers deployed at a minimum, as described in Best Practices, below. However, most of these events are accidental, where a second DHCP server is installed by someone who is unaware of other DHCP servers already active on the network.

The DHCP server for Windows 2000 has management features to prevent unauthorized deployments and to detect existing unauthorized DHCP servers. In the past, anyone could bring up a DHCP server on a network. Today, an authorization step is required. These authorized personnel are usually the administrator of the domain that the Windows 2000 Server platform belongs to or someone to whom they have delegated the task of managing the DHCP servers.

Protecting Against Unauthorized DHCP Servers

Active Directory is now used to store records of authorized DHCP servers. When a DHCP server comes up, the directory can now be used to verify the status of that server. If that server is unauthorized, no response is returned to DHCP requests. A network manager with the proper access rights has to respond. The domain administrator can assign access to the DHCP folder holding configuration data, to allow only authorized personnel to add DHCP servers to the approved list.

The list of authorized servers can be created in the Active Directory through the DHCP snap-in. When it first comes up, the DHCP server tries to find out if it is part of the directory domain. If it is, it tries to contact the directory to see if it is in the list of authorized servers. If it succeeds, it sends out DHCPINFORM to find out if there are other directory services running and makes sure that it is valid in others, as well. If it cannot connect the directory, it assumes that it is not authorized and does not respond to client requests. Likewise, if it does reach the directory but does not find itself in the authorized list, it does not respond to clients. If it does find itself in the authorized list, it starts to service client requests.

Protecting Against Improper Use of Workgroup DHCP Servers

When a DHCP server that is not a member server of the domain (such as a member of a workgroup) comes up, the following happens: The server broadcasts a DHCPINFORM message on the network. Any other server that receives this message responds with DHCPACK message and provides the name of the directory domain it is part of. If a workgroup DHCP server detects another member DHCP server of a domain on the network, the workgroup DHCP server assumes that it is unauthorized on that network and does not service requests. If the workgroup DHCP server detects the presence of another workgroup server, it ignores it; this means that there can be multiple workgroup servers active at the same time, as long as there is no directory service.

Even when a workgroup server comes up and finds itself allowed to run (because no other domain member server or workgroup server is on the network), it continues to probe DHCPINFORM every five minutes. If an authorized domain member DHCP server comes up later, the workgroup server becomes unauthorized and stops servicing.

Windows Clustering for High Availability

Windows Clustering allows two servers to be managed as a single system. Windows Clustering can be used for DHCP servers to provide higher availability, easier manageability, and greater scalability.

Windows Clustering can automatically detect the failure of an application or server and quickly restart it on a surviving server; users would only experience a momentary pause in service. With Windows Clustering, administrators can quickly inspect the status of all cluster resources and easily move workload around onto different servers within the cluster. This is useful for manual load balancing and for performing rolling updates on the servers without taking important data and applications offline.

Windows Clustering allows DHCP servers to be virtualized so that if one of the clustered node crashes, the name space and all the services are transparently reconstituted to the second node. This means no changes for the client, which sees the same IP address for the clustered DHCP server.

Without clustering, network administrators might split scopes between servers, so if one server goes down, at least half of the available addresses remain available. Clustering makes more efficient use of IP addresses by removing the need to split scopes. A database that is stored on a remote disk tracks address assignment and other activity so that if the active cluster node goes down, the second node becomes the DHCP server, with complete knowledge of what has been assigned and access to the complete scope of addresses. Only one node at a time runs as a DHCP server, with the Windows Clustering remotely stored database providing transparent transition when needed.

Because Windows Clustering works with all clustering-enabled Windows services, the same cluster servers used for DHCP support high availability for all other clustering-enabled Windows services, as well.

Automatic Client Configuration

A compelling new feature of the DHCP client in Windows 2000 is the ability to automatically configure an IP address and subnet mask when the client is started on a small private network where no DHCP server is available to assign addresses.

If a Microsoft TCP/IP client is installed and set to dynamically obtain TCP/IP protocol configuration information from a DHCP server, rather than being manually configured with an IP address and other parameters, the DHCP client service is engaged each time the computer is restarted.

The DHCP client service now uses a two-step process to configure the client with an IP address and other configuration information.

When the client is installed, it attempts to locate a DHCP server and obtain a configuration from it. Most corporate TCP/IP networks use DHCP servers, which have been administratively configured to dispense information to clients on the network. For Windows 2000-based platforms, if the first attempt to locate a DHCP server fails, the DHCP client configures itself with a selected IP address.

If the DHCP client has previously obtained a lease from the DHCP server, the client tries to renew any unexpired lease with the DHCP server. If the client fails to locate any DHCP server, it attempts to ping the default gateway listed in the lease. If this succeeds, the client assumes it has not been moved and uses that lease. The client then seeks to automatically renew the lease when half of the lease time has expired.

If the attempt to ping the default gateway fails, the client assumes that it has been moved to a network that has no DHCP services currently available, such as a home network and it configures itself. It then automatically keeps trying to find a DHCP server every five minutes.

DHCP Overview

Dynamic Host Configuration Protocol was derived from the Internet standard Bootstrap Protocol (BOOTP) (RFCs 951 and 1084), which allowed dynamic assignment of IP addresses (as well as remote-booting of diskless work stations). In addition to supporting dynamic assignment of IP addresses, DHCP supplies all configuration data required by TCP/IP, plus additional data required for specific servers.

As noted, this makes life easier for the network administrator, who can now manually configure just one machine—the DHCP server. Whenever a new host is plugged into the network segment that is served by the DHCP server (or an existing host is turned back on), the machine asks for a unique IP address, and the DHCP server assigns it one from the pool of available IP addresses.

This process, shown in Figure 1 below, involves just four steps: The DHCP client asks for an IP address (DHCP Discover), is offered an address (DHCP Offer), accepts the offer and requests the address (DHCP Request), and is officially assigned the address (DHCP Acknowledge).

Figure 1: DHCP automates the assignment of IP addresses

To make sure addresses are not wasted, the DHCP server places an administrator-defined time limit on the address assignment, called a lease. Halfway through the lease period, the DHCP client requests a lease renewal, and the DHCP server extends the lease. This means that when a machine stops using its assigned IP address (for example, on being moved to another network segment or being retired), the lease expires, and the address is returned to the pool for reassignment.

Server, Clients, and Relay Agents

Microsoft DHCP is based on three basic components:

• DHCP Servers

• DHCP Clients

• DHCP/BOOTP Relay Agents

DHCP Servers

The Microsoft DHCP server includes DHCP Manager, an easy-to-use graphical user interface management tool that allows network administrators to define DHCP client configurations. The DHCP server also includes a database for managing assignment of IP addresses and other configuration parameters.

The Microsoft DHCP server supports more than 30 DHCP options, as defined by the RFC 2132. These options are listed in the Appendix. TCP/IP configuration parameters that can be assigned by the DHCP server include:

• IP addresses for each network adapter in a client computer.

• Subnet masks that are used to identify the IP network portion from the host portion of the IP address.

• Default gateways (routers), which are used to connect a single network segment to others.

• Additional configuration parameters that can optionally be assigned to DHCP clients (such as IP addresses for DNS or WINS servers a client may use).

One or more computers on a network must run Windows NT Server with the TCP/IP protocol and the DHCP server installed to provide clients with dynamic IP addresses. After the DHCP server service is installed on a computer running Windows NT Server, a Microsoft DHCP server database is automatically created once scopes are created and activated.

DHCP Clients

Many low-cost industry standard platforms can act as DHCP clients, as defined with the updated RFC 2132 specification.

The four steps necessary for a DHCP client to acquire a lease from a DHCP server are initiated automatically when the computer is first booted. The minimal client configuration that DHCP requires can be enabled quickly during client setup and installation or by performing a brief manual resetting of client TCP/IP properties. Hosts running the following Microsoft operating systems can act as DHCP clients:

• Windows NT Workstation (all released versions)

• Windows NT Server (all released versions)

• Windows 98

• Windows 95

• Windows for Workgroups version 3.11 (with the Microsoft 32-bit TCP/IP VxD installed)

• Microsoft Network Client version 3.0 for the Microsoft MS-DOS® operating system (with the real-mode TCP/IP driver installed)

• LAN Manager version 2.2c

In addition to supplying configuration information through DHCP, Network Administrators may also override dynamic settings with manual ones. Any information manually entered into a client's TCPIP configuration overrides dynamic settings.

Figure 2: Three DHCP configurations showing the use of the DHCP BOOTP relay agent

BOOTP/DCHP Relay Agent

The BOOTP and DHCP Protocols rely on Network Broadcasts to perform their work. Routers in normal routed environments do not automatically forward Broadcasts from one interface to another; therefore, a relay agent must be used to pass along this communication. A DHCP relay agent is either a router or a host computer configured to listen for DHCP/BOOTP broadcast messages and direct them to a specific DHCP Server(s). Using relay agents eliminates the necessity of having a DHCP server on each physical network segment. Relay agents not only direct local DHCP client requests to remote DHCP servers but also return remote DHCP server responses to the DHCP clients.

RFC 2131–compliant routers (supersedes RFC 1542) contain relay agents that allow them to forward DHCP packets.

Windows NT Server also comes with a DHCP Relay Agent that may be installed and configured as a service. Three common designs are shown.

Managing DHCP

DHCP Manager helps network administrators configure and monitor DHCP servers. Network administrators may define global and scope-specific configuration settings to identify routers and set DHCP client configurations.

The Microsoft DHCP server database is automatically created when Microsoft DHCP server is installed on a computer running Windows NT Server and TCP/IP.

DHCP Scopes

A DHCP scope is an administrative grouping that identifies the full consecutive ranges of possible IP addresses for all DHCP clients on a physical subnetwork. Scopes define a logical subnetwork for which DHCP services are to be offered, and also allow the server to identify configuration parameters that are given to all DHCP clients on the subnetwork. A scope must be defined before DHCP clients can use the DHCP server for dynamic TCP/IP configuration.

Address Pools

Once a DHCP scope is defined and exclusion ranges are applied, the remaining addresses form what is called an available address pool within the scope. Pooled addresses may then be dynamically assigned to DHCP clients on the network.

ExclusionRanges

An exclusion range is a limited sequence of IP addresses within a scope range that are to be excluded from DHCP service offerings. Where exclusion ranges are used, they ensure that any addresses within the defined exclusion range are not offered to clients of the DHCP server.

Reservations

Reservations allow permanent address lease assignment by the DHCP server. Where reservations are used, they ensure that a specified hardware device on the subnetwork can always use the same IP address.

Superscopes

An administrative feature included within the Microsoft DHCP Manager tool can be used to create a number of distinct scopes, which are grouped together into a single administrative entity called a superscope. Superscopes are useful for solving several different DHCP service issues.

Leases

As noted, a lease is the length of time that that a DHCP server specifies that a client computer can use an assigned IP address. When a lease is made to a client, it is described as active. At half-lease period, the client must renew its address lease assignment with the server. The duration of leases affects how often clients attempt to renew those they have been assigned with the DHCP server.

DHCP Options

DHCP Options are other client-configuration parameters that a DHCP server can assign when serving leases to DHCP clients. For example, IP addresses for a router or default gateway, WINS servers, or DNS servers are commonly provided for a single scope or globally for all scopes managed by the DHCP server. Many DHCP options are predefined through RFC 2132, but the Microsoft DHCP server also allows defining and adding custom options.

DHCP Deployment

DHCP has become such an important element of efficient network design that network administrators want to ensure proper DHCP deployment. Basic considerations of DHCP deployment include:

• Determining the number of DHCP servers to use.

• Determining and configuring scopes.

• Using superscopes.

• Reserving IP addresses.

• BOOTP tables.

Determining the Number of DHCP Servers to Use

One online DHCP server and one backup DHCP server can support a large number of clients, depending on hardware configurations and other issues. However, when deciding how many DHCP servers are necessary, the location of routers on the network and whether a DHCP server is desired in each subnet needs to be considered. The transmission speed between each segment for which DHCP service is to be provided should also be considered. With slower WAN links or dial-up links, a DHCP server is typically deployed on both sides of these links to service clients locally.

A network can have practical size constraints, based on the IP address class, such as the 254-node limit of Class C networks. In addition, server configuration issues, such as disk capacity and CPU speed, are critical factors.

Defining and Configuring Scopes

A scope is an administrative grouping of computers for a subnetwork using DHCP service. Administrators create a scope for each physical subnetwork, which is then used to define parameters used by clients for this subnetwork. Scopes can be planned based on the needs of particular groups of users, with appropriate lease durations defined for the related scopes. A scope has the following properties:

• A range of possible IP addresses from which to include or exclude addresses used in DHCP service lease offerings.

• A unique subnet mask to determine the subnet related to a given IP address.

• A scope name assigned when the scope is created.

• Lease duration values to be assigned to DHCP clients that receive dynamically allocated IP addresses.

• Reservations.

• Options.

A DHCP scope consists of a pool of IP addresses on a subnetwork, such as 10.223.223.1 to 10.223.223.200, that the DHCP server can lease to DHCP clients. Each physical network can have only one DHCP scope or a superscope with one or more ranges of IP addresses.

To use several address ranges within a single scope or subnetwork for DHCP service, it is necessary to do the following:

• Define the scope. Use the entire range of consecutive IP addresses that make up the local IP subnetwork for which DHCP service is being enabled.

• Set exclusion ranges as needed. Exclusions should be set for any IP addresses within the scope that are not to be offered or used for DHCP assignment by the DHCP server. For example, the first 10 addresses in the previous example scope can be excluded by creating an exclusion for 10.223.223.1 to 10.223.223.10. Doing so specifies that no DHCP clients ever receive these addresses for leased configuration. The only way an excluded IP address range can be active on a network is if these addresses are manually configured for use on other devices that cannot use DHCP.

• A defined scope can be further configured via the following additional tasks.

• Select further exclusion ranges as needed. Choices can be made to further exclude any IP addresses not to be leased to DHCP clients. Exclusions should be used for all devices that are not DHCP-capable, such as printers.

• Create reservations as needed. A choice can be made to reserve some IP addresses for permanent lease assignment to specified computers or devices on a network. Reservations should only be made for devices that are DHCP-enabled and that must be reserved for special reasons on the network, such as special server computers (servers used for DHCP, WINS, or DNS) and routers.

• Adjust the duration of leases. The lease duration to be used when assigning IP address leases can be modified. The default lease duration is three days. In most cases, the default value is acceptable, and no further adjustment is needed, although this setting can be modified.

• Define options.

After a scope has been defined and fully configured, as outlined above, it must then be activated before dynamic service begins for DHCP-enabled clients. Once a scope is active, the server can begin processing IP lease requests and offering IP leases to DHCP-enabled clients on the network.

Using Superscopes

The superscope feature described earlier is useful for solving several different DHCP service issues. Superscopes let Microsoft DHCP servers:

• Support DHCP clients on a single physical network segment having multiple logical IP subnets, often called multinets.

• Support remote DHCP clients located on the far side of BOOTP/DHCP relay agents (where the network on the far side of the agent uses multinets).

On Windows NT 4.0 Service Pack 2 and later, the DHCP server versions may assign addresses from more than one scope to a physical subnet.

Situations for which superscopes are useful include the following:

• More hosts must be added on a wire than originally planned.

• The network is renumbered.

• Two DHCP servers are used to manage separate logical subnets on the same physical subnet.

The following table, Figure 2, shows two DHCP servers that are both reachable on the same physical subnet and configured with a single scope.

DHCP server name	Starting IP address	Ending IP address
DHCP-ServerA	211.111.111.1	211.111.111.255
DHCP-ServerB	222.222.222.1	222.222.222.255

Figure 3 DHCP servers A and B are reachable on the same physical subnet and are each configured with a single scope

If DHCP-Server A manages a different scope of addresses than DHCP-Server B and neither has any information about addresses managed by the other, a problem arises if a client previously registered with Server A, for example, releases its name during a proper shutdown and later reconnects to the network after a reboot. The client tries to renew its previously leased IP address.

If Server B receives a DhcpRequest packet from the client to renew use of an address before Server A does, Server B, being unaware of that IP address, causes it to reject the request and send a DhcpNak packet to the client. The client must then renegotiate a DHCP lease by broadcasting a DhcpDiscover packet onto the local subnet. Server B can send a DhcpOffer packet, offering the client an address. The client can accept the address by returning a DhcpRequest for that address to Server B for approval. When Server B approves the address assignment, it returns a DhcpAck packet to the client.

Several DHCP service problems occur within this example:

• Nothing prevents a client from having its attempt to renew a previous address rejected each time it connects to the network.

• In the process of rejecting and re-obtaining an address lease, the client may be offered an address that places it on a different subnet from the one for which it was previously configured.

Using superscopes on both DHCP servers avoids both of these problems and allows addresses be managed more predictably and effectively.

Superscopes can be used to avoid such problems by taking the following steps:

1. Create a new scope on a server that contains the respective scope information for the other. For example, on DHCP-Server A, create a new scope with the range of 222.222.222.1 to 222.222.222.255. Be sure to also create an exclusion range for the new scope for all scope addresses (222.222.222.1 to 222.222.222.255).

2. Repeat the previous step for the other DHCP server. For example, on DHCP-Server B, create a new scope with the range of 211.111.111.1 to 211.111.111.255, as well as an exclusion range for this new scope for all scope addresses (211.111.111.1 to 211.111.111.255).

3. Create a superscope on each DHCP server by using the Add Superscope wizard. Add both the old and the new scopes to the superscopes thus created.

4. Activate the new scopes on each server.

By configuring superscopes as described, DHCP-Servers A and B each recognize IP addresses assigned by the other. This prevents either server from negatively acknowledging attempts by DHCP clients to renew their same IP address or to obtain an address from the same logical range of addresses, in other words, a different address within the same logical subnet. Before a superscope can be created, DHCP Manager must be used to define all scopes to be included in the superscope. (Guidance on creating superscopes is provided in DHCP Manager online Help.)

Reserving IP Addresses

DHCP Manager allows the reservation of a specific IP address for a computer or other IP addressable device on the network. Reserving selected IP addresses for special-function devices on the network ensures that DHCP does not duplicate or reassign the address. Reservations can be useful for the following types of devices and computers:

• Other Windows NT Server–based computers on the network that require static IP addresses, such as WINS servers.

• Any print servers that use TCP/IP print services.

• UNIX, or other, clients that use IP addresses assigned by another TCP/IP configuration method.

• Any DNS servers on the network, whether running Windows NT or not.

Each reservation requires a unique identifier to be obtained for the device for which an address is reserved, which is the same as the Media Access Control (MAC) or physical address for the DHCP client. In the case of Ethernet, this address is a unique sequence of hexadecimal byte numbers and is used to identify the network adapter hardware for each network-connected device.

(To obtain MAC addresses on Windows NT–based clients, type "ipconfig /all" at the command prompt and view the Physical Address field. For Windows 95–based clients, run Winipcfg.exe, and view the Adapter Address field.)

BOOTP Tables

As noted, the Bootstrap protocol lets diskless clients obtain their own IP addresses and other boot information needed for network startup. BOOTP preceded DHCP and is now used mainly in UNIX environments. For this reason, many Windows NT-based installations do not need BOOTP, so the BOOTP table need not be configured.

BOOTP lets diskless clients use User Datagram Protocol (UDP) packets to request and retrieve an IP address and a small boot image file from a Trivial File Transfer Protocol (TFTP) server.

The Microsoft DHCP server offers BOOTP support in the form of pointer records contained in the BOOTP table. Data stored there is returned to any BOOTP clients on the network that broadcast a BOOTP request message. If a BOOTP record exists in the BOOTP table, the Microsoft DHCP server returns a BOOTP message to the requesting BOOTP client, and if no BOOTP records are configured, the Microsoft DHCP server silently ignores BOOTP request messages.

The reply message returned by the Microsoft DHCP server indicates the name and location of a TFTP server on the network that the client can then contact to retrieve its boot image file. Each record in the BOOTP table contains the following three fields, which contain the information returned to the BOOTP client:

• The Boot Image identifies the generic file name of the boot file requested, based on the BOOTP client's computer type.

• The File Name identifies the full path of the boot file returned by TFTP by the BOOTP server to the client.

• The File Server identifies the TFTP server used to source the boot file.

The DHCP Manager can add, remove, and edit records in the BOOTP table.

Unlike DHCP, BOOTP does not permit dynamic address leases, so BOOTP clients assume any IP address granted to them to be permanent. This resembles address management for reserved DHCP clients. Where BOOTP is used, the range of IP addresses that are reserved for BOOTP service on a network must be excluded from any DHCP scopes that are set up and configured. If the BOOTP client does not request options, none are provided, possibly rendering the BOOTP client inoperative because it did not receive a default gateway or a DNS server.

Best Practices

Certain practices that optimize the functionality and performance of the Microsoft DHCP server are described below.

Optimizing Lease Management Practices

Since lease renewal is an ongoing process that can affect the performance of DHCP clients and the network, it is sometimes desirable to use a different lease duration. When this is necessary, the following guidelines can help you decide how to best modify lease duration settings for improving DHCP performance on the network.

Lengthening Lease Duration

Increase scope lease length for large, stable fixed networks where scope address space is plentiful. If many IP addresses are available and configurations rarely change, increasing the lease duration lowers the frequency of lease renewal queries between clients and the DHCP server, thus reducing associated network traffic. This is most useful for larger routed networks, where lengthening the default lease period to perhaps 7 to 21 days reduces DHCP-related network broadcast traffic, particularly if client computers generally remain in fixed locations and scope addresses are plentiful, such as with less than 80 percent in use.

Shortening Lease Duration

By contrast, if few IP addresses are available and either client configurations or network locations change, reducing the lease duration increases the rate at which addresses are returned to the available address pool for reassignment to new clients by the DHCP server. This would be especially beneficial in a sales organization, for example, which might issue laptop computers to traveling personnel, or for business units that relocate computers frequently.

Neither of these guidelines need be used on all scopes on a given DHCP server. Some mix of the two is usually the correct decision. With a single segment where laptops are coming and going, shortening the lease on that scope would be a good choice, while other parts of a network with a stable body of clients could set the lease duration somewhat higher. Decisions should be made on a scope-by-scope basis.

Integrate DHCP with Other Services

Both WINS and DNS can be used to register dynamic name-to-address mappings on a network. Operating DHCP with other name-resolution services requires careful planning, and network administrators implementing DHCP should also develop a strategy for implementing DNS and WINS servers.

Upgrading Routers

Where routers connect multiple physical networks, it is useful to configure them to relay BOOTP/DHCP messages if possible. Many routers employ vendor-specific router commands or configurable router settings to enable BOOTP/DHCP relay, such as the IP HELPER command used in some Cisco routers. If a router does not support BOOTP/DHCP relay, a router upgrade from the vendor might. DHCP and BOOTP message traffic may be relayed on the same router because they have a common message format.

If a router upgrade is not possible, an additional Windows NT-based platform can be configured to serve as a DHCP relay agent for its network segment. This computer then relays traffic between DHCP-enabled clients on the local physical network and a remote DHCP server located on another physical network.

Determining the Number of DHCP Servers Needed

It is important to carefully determine how many DHCP servers are needed to service all DHCP-enabled clients on the network. In a small LAN, such as one physical subnetwork without routers, a single DHCP server may service all DHCP-enabled clients. However, routed networks may require several DHCP servers.

While there is no theoretical limit to the maximum number of clients that can be served by a single DHCP server, there are practical constraints based on the IP address class of the network and server configuration issues, such as disk capacity and CPU speed.

Transmission speed between each segment for which DHCP service is provided is an important factor. With slower WAN links or dial-up links, a DHCP server is typically needed on both sides of these links to service clients locally. Another factor is whether DHCP service is used in all or only selected physical networks. When deploying multiple DHCP servers for an environment, it is advisable to place them on different network segments for the case where a network segment becomes unreachable. DHCP Relay agents turn the broadcast into a unicast packet.

Before installing the DHCP server, it is necessary to identify:

• The hardware and storage requirements for the DHCP server.

• Which computers are immediately configurable as DHCP clients for dynamic TCP/IP configuration and which must be manually configured with static TCP/IP configuration parameters, such as static IP addresses.

• The DHCP option types and their values to be predefined for DHCP clients.

• DHCP Relay Agent configurations for a network.

Fault-Tolerant Planning

It is a good idea to split a scope between two or three servers. In this way, one can handle DHCP traffic flood more easily. In addition, if a server goes down, the network is not affected. . A 70/30 split seems to offer the optimum benefit.

For example, consider a Class B scope 132.255.0.0 with address range from 132.255.0.1-132.255.255.255 and subnet mask 255.255.0.0. One setup would be to distribute the load between two servers (SRV1 and SRV2). SRV1 has a scope of 132.255.0.1-132.255.255.255 with a mask of 255.255.0.0. The exclusion range for this scope is 132.255.128.0-132.255.255.255. SRV2 has a scope of 132.255.0.1-132.255.255.255 with a mask of 255.255.0.0. The exclusion range for this scope is 132.255.0.1-132.127.255.255. A scope can also be divided between three servers in a similar way.

Proper Superscope Implementation

Although superscopes can ease DHCP management, they are not required just because a DHCP server is handling more than one scope (subnet ID). A single DHCP server can be used to serve two or more physically different subnets separated by a router, where BOOTP/DHCP relay agents are configured to provide relay of client requests for scopes that service subnets located away from the DHCP server. Relay agents are typically included with your routers and, where used, must be configured with IP addresses for your DHCP servers.

Configuring Multiple DHCP Servers for the Same Superscope

When more than one DHCP server is used to service a superscoped segment, the superscope for each DHCP server should be configured to include all subnets, using placeholder values for subnets it does not supply addresses to, but must recognize as valid.

For example, consider a segment running four logical IP subnets (192.168.1.0, 192.168.2.0, 192.168.3.0, and 192.168.4.0, all with mask 255.255.255.0). This segment is supported by two DHCP servers, each configured with a superscope covering half of the subnets (SRV1's superscope contains only subnets 192.168.1.0 and 192.168.2.0, and SRV2's superscope contains only subnets 192.168.3.0, 192.168.4.0). As DHCP requests come in from clients, addresses can be assigned from either of the servers' scopes. However, a problem can arise if a client is given an IP address from SRV1, and then its renewal request is received by SRV2. SRV2 does not recognize the client's address as belonging to that subnet and responds to the client by sending a DHCP NACK.

This problem is easily avoided by configuring both SRV1 and SRV2 with all logical IP subnets and using exclusions to prevent the servers from overlapping address ranges. SRV1 should have a superscope containing all four subnets and exclude all the addresses of the last two subnets, and SRV2 should also have a superscope containing all four subnets and exclude all the addresses of the first two subnets.

BOOTP Relay Configuration

Proper deployment of DHCP servers prevents BOOTP relay agents from generating duplicate packets, which can cause the DHCP server to receive several copies of the same Discover or Request.

For example, the two BOOTP Relay designs shown below have the same number of networks, servers, and routers, but the first one causes eight packets to reach the DHCP servers for every DHCP Packet sent by a client.

Figure 4: This network design causes eight packets to be sent to the DHCP server for every packet sent from the client

Figure 5: This network design eliminates duplicate packets, while providing enough fault-tolerant redundancy that any single part of the network can fail and clients still get leases

Future

Looking into the future, Microsoft DHCP is designing Dynamic BOOTP, authenticated DHCP, and DHCP version 6.

Summary

As the world of networking continues to converge on the TCP/IP protocols, Dynamic Host Configure Protocol becomes an ever more important element in efficient network design.

DHCP provides safe and reliable TCP/IP network configuration. DHCP service also helps prevent IP address conflicts and conserves the use of IP addresses through centralized management of address allocation. In contrast to manual configuration, where each client computer must have its IP address information individually set before it can join the network, DHCP offers a form of instant access for supported clients that use DHCP.

The Microsoft DHCP server for Windows 2000 builds on a long history of support for DHCP and adherence to open industry standards, while introducing features that make DHCP easier to deploy and manage. Network managers benefit from the integration of DHCP with the domain name system (DNS), enhanced monitoring and statistical reporting for DHCP servers, new vendor-specific options and user-class support, multicast address allocation, unauthorized DHCP server detection, and plans for Windows Clustering.

The Microsoft DHCP server combines with the Windows NT operating system and other Windows NT services to give network administrators the tools that they need to deploy robust, high-performance, scalable, and easily configurable networks.

Appendix A: Predefined Options for DHCP CLients

The tables in this section describe the predefined options available for configuring DHCP clients. These options are defined in RFC 1533. Options listed in bold are options that Microsoft DHCP clients receive by default.

Basic Options

Code	Option name	Meaning
0	Pad	Causes subsequent fields to align on word boundaries.
255	End	Indicates end of options in the DHCP packet.
1	Subnet Mask
2	Time offset	Specifies the Universal Coordinated Time (UCT) offset in seconds.
3	Router	Specifies a list of IP addresses for routers on the client's subnet.¹
4	Time server	Specifies a list of IP addresses for time servers available to the client.¹
5	Name servers	Specifies a list of IP addresses for name servers available to the client.¹
6	DNS servers	Specifies a list of IP addresses for DNS name servers available to the client.¹
7	Log servers	Specifies a list of IP addresses for MIT_LCS User Datagram Protocol (UDP) log servers available to the client.¹
8	Cookie servers	Specifies a list of IP addresses for RFC 865 cookie servers available to the client.¹
9	LPR servers	Specifies a list of IP addresses for RFC 1179 line-printer servers available to the client.¹
10	Impress servers	Specifies a list of IP addresses for Imagen Impress servers available to the client.¹
11	Resource location servers	Specifies a list of RFC 887 Resource Location servers available to the client.¹
12	Host name	Specifies the host name of up to 63 characters for the client. The name must start with a letter, end with a letter or digit, and have as interior characters only letters, numbers, and hyphens. The name can be qualified with the local DNS domain name.
13	Boot file size	Specifies the size of the default boot image file for the client, in 512-octet blocks.
14	Merit dump file	Specifies the ASCII path name of a file where the client's core image is dumped if a crash occurs.
15	Domain name	Specifies the DNS domain name that the client should use for DNS host name resolution.
16	Swap server	Specifies the IP address of the client's swap server.
17	Root path	Specifies the ASCII path for the client's root disk.
18	Extensions path	Specifies a file retrievable through TFTP, containing information interpreted like the vendor-extension field in the BOOTP response, except that the file length is unconstrained and references to Tag 18 in the file are ignored.

¹ List is specified in order of preference.

The following table lists IP layer parameters on a per-host basis.

IP Layer Parameters per Host

Code	Option name	Meaning
19	IP layer forwarding	Enables or disables forwarding of IP packet for this client: 1 enables forwarding; 0 disables it.
20	Nonlocal source routing	Enables or disables forwarding of datagrams with nonlocal source routes. 1 enables forwarding; 0 disables it.
21	Policy filter masks	Specifies policy filters that consist of a list of pairs of IP addresses and masks specifying destination/mask pairs for filtering nonlocal source routes. Any source routed datagram whose next-hop address does not match a filter is discarded by the client.
22	Max DG reassembly size	Specifies the maximum size datagram that the client can reassemble. The minimum value is 576.
23	Default time-to-live	Specifies the default time-to-live (TTL) that the client uses on outgoing datagrams. The value for the octet is a number between 1 and 255.
24	Path MTU aging time-out	Specifies the time-out in seconds for aging Path Maximum Transmission Unit (MTU) values (discovered by the mechanism defined in RFC 1191).
25	Path MTU plateau table	Specifies a table of MTU sizes to use when performing Path MTU Discovered as defined in RFC 1191. The table is sorted by size from smallest to largest. The minimum MTU value is 68.

The following table lists IP parameters on a per-interface basis. These options affect the operation of the IP layer on a per-interface basis. A client can issue multiple requests, one per interface, to configure interfaces with their specific parameters.IP Parameters per Interface

Code	Option name	Meaning
26	MTU option	Specifies the MTU discovery size for this interface. The minimum MTU value is 68.
27	All subnets are local	Specifies whether the client assumes that all subnets of the client's internetwork use the same MTU as the local subnet where the client is connected. 1 indicates that all subnets share the same MTU; 0 indicates that the client should assume some subnets may have smaller MTUs.
28	Broadcast address	Specifies the broadcast address used on the client's subnet.
29	Perform mask discovery	Specifies whether the client should use Internet Control Message Protocol (ICMP) for subnet mask discovery. 1 indicates that the client should perform mask discovery; 0 indicates that the client should not.
30	Mask supplier	Specifies whether the client should respond to subnet mask requests using ICMP. 1 indicates that the client should respond; 0 indicates that the client should not respond.
31	Perform router discovery	Specifies whether the client should solicit routers using the router discovery method in RFC 1256. 1 indicates that the client should perform router discovery; 0 indicates that the client should not use it.
32	Router solicitation address	Specifies the IP address to which the client submits router solicitation requests.
33	Static route	Specifies a list of IP address pairs that indicate the static routes the client should install in its routing cache. Any multiple routes to the same destination are listed in descending order or priority. The routes are destination/router address pairs. (The default route of 0.0.0.0 is an illegal destination for a static route.)

The following table lists link layer parameters per interface. These options affect the operation of the data link layer on a per-interface basis.

Link Layer Parameters per Interface

Code	Option name	Meaning
34	Trailer encapsulation	Specifies whether the client should negotiate use of trailers (RFC 983) when using the ARP protocol. 1 indicates that the client should attempt to use trailer; 0 indicates that the client should not use trailers.
35	ARP cache time-out	Specifies the time-out in seconds for ARP cache entries.
36	Ethernet encapsulation	Specifies whether the client should use Ethernet version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the interface is Ethernet: 1 indicates that the client should use RFC 1042 encapsulation; 0 indicates that the client should use RFC 894 encapsulation.

The following table shows TCP parameters. These options affect the operation of the TCP layer on a per-interface basis.

TCP Parameters

Code	Option name	Meaning
37	Default time-to-live	Specifies the default TTL the client should use when sending TCP segments. The minimum value of the octet is 1.
38	Keep-alive interval	Specifies the interval in seconds the client TCP should wait before sending a keep-alive message on a TCP connection: 0 indicates that the client should not send keep-alive messages on connections unless specifically requested by an application.
39	Keep-alive garbage	Specifies whether the client should send TCP keep-alive messages with an octet of garbage data for compatibility with older implementations: 1 indicates that a garbage octet should be sent; 0 indicates that it should not be sent.

The following table shows application layer parameters. These miscellaneous options are used to configure applications and services.

Application Layer Parameters

Code	Option name	Meaning
40	NIS domain name	Specifies the name of the Network Information Service (NIS) domain as an ASCII string.
41	NIS servers	Specifies a list of IP addresses for NIS servers available to the client.¹
42	NTP servers	Specifies a list of IP addresses for Network Time Protocol (NTP) servers available to the client.¹

¹ List is specified in order of preference.

The following options are for vendor-specific information.

Code	Option name	Meaning
43	Vendor-specific info	Binary information used by clients and servers to exchange vendor-specific information. Servers not equipped to interpret the information ignore it. Clients that do not receive the information attempt to operate without it.

NetBIOS over TCP/IP

Code	Option name	Meaning
44	WINS/NBNS servers	Specifies a list of IP addresses for NetBIOS name servers (NBNS).¹
45	NetBIOS over TCP/IP NBDD	Specifies a list of IP addresses for NetBIOS datagram distribution servers (NBDD).¹
46	WINS/NBT node type	Allows configurable NetBIOS over TCP/IP clients to be configured as described in RFC 1001/1002, where 1=b-node, 2=p-node, 4=m-node, and 8=h-node.
47	NetBIOS scope ID	Specifies a string that is the NetBIOS over TCP/IP Scope ID for the client, as specified in RFC 1001/1002.
48	X Window system font	Specifies a list of IP addresses for X Window font servers available to the client.¹
49	X Window system display	Specifies a list of IP addresses for X Window System Display Manager servers available to the client.¹

¹ List is specified in order of preference.

DHCP Extensions

Code	Option name	Meaning
58	Renewal (T1) time value	Specifies the time, in seconds, from address assignment until the client enters the renewing state.
59	DHCPDISCOVER packet	Rebinding (T2) time value

Specifies the time in seconds from address assignment until the client enters the rebinding state. If the lease expires, the client must immediately discontinue using the IP address and begin negotiating a new lease.

Appendix B: Windows NT 4.0 Server Performance Measurement

This appendix contains information on server performance measurement, including the specification of server hardware used for the testing.

Server Hardware Specification

The DHCP server performance was measured on a Compaq Proliant 5500 Server. The machine specifications are as follows:

• Dual processor 200MHZ Pentium Pro with 512 KB L2 cache

• 256 MB of RAM

• Hardware Raid 0 across eight 2 GB data drive—total data space = 16 GB

• Windows NT Server operating system is on a 4 GB volume

• Network 100base Tx Fast Ethernet

• NIC: Compaq Dual Netflex3

The DHCP database path was modified to be in the raided D: drive. The DHCP database backup path was also modified to be in the D: drive.

Server Performance Degradation with the Number of Leases

One hundred clients were simulated against the server. The clients repeatedly asked for a new lease with a new hardware address or asked for the lease to be renewed with an old IP address. The clients would use DISCOVER to ACK 80 percent of the time and REQUEST to ACK 20 percent of the time. Audit logging was turned on, and conflict detection was turned off. The test was run for a period of twelve hours. The following table illustrates the number of RENEWS, new leases given out by the server:

Time (in hours )	Number of leases obtained, renewed
11:00	0
12:00	61740
13:00	123420
14:00	185460
15:00	247320
16:00	308100
17:00	370020
18:00	431580
19:00	493020
20:00	554640
21:00	615960
22:00	677100
23:00	737340

Server Performance with the Number of Scopes

The clients were simulated against the server in this test. The average ACKS given out by the server per minute was measured. The total number of renewals, new leases used in this experiment is 10,000. The clients did DISCOVER-OFFER 20 percent of the time and REQUEST-ACK 80 percent of the time.

Total number of scopes	Average leases per minute issued by the server for 10,000 renewals, new leases.
2	960
100	960
1000	960
10000	960
20000	960

0399

For More Information

For the latest information on Windows 2000, check out Microsoft TechNet or visit the Web site at https://www.microsoft.com/ntserver/ and the Windows NT Server Forum, https://www.microsoft.com/windows2000/community/default.mspx. An excellent source of DHCP information is found at: https://www.watersprings.org/pub/id/draft-ietf-dhc-dhcpv6-21.txt