Dynamic Host Configuration Protocol for Windows 2000

White Paper

Abstract
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.

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.

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.

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 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.

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.

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.

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 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.

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.

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.

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.

Exclusion Ranges

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.

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.

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.

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.)

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.)

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.

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.

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.

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.

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.

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.
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.

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.

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.
For the latest information on Windows 2000, check out Microsoft TechNet or visit the Web site at
http://www.microsoft.com/ntserver/ and the Windows NT Server Forum on MSN™,
http://computingcentral.msn.com/forums/default.asp?windowsnt .

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.
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.

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.

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
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.
Average leases per minute issued by the server for 10,000
Total number of scopes
renewals, new leases.
2 960
100 960
1000 960
10000 960
20000 960