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.

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.
Top of page
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
(http://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.
Top of page
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

See full-sized image.
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
See full-sized image.
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.
Top of page
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.
Top of page
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
See full-sized image.
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
See full-sized image.
Top of page
Future
Looking into the future, Microsoft DHCP is designing Dynamic BOOTP, authenticated DHCP, and DHCP version 6.
Top of page
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.
Top of page
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 Specifies a list of RFC 887 Resource Location servers available to the
servers 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.
Code Option name Meaning

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.¹
Code Option name Meaning

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.
Top of page
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