What Is DHCP?

What Is DHCP?
Updated: March 28, 2003
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2
What is DHCP?
Dynamic Host Configuration Protocol (DHCP) is a client/server protocol that automatically provides an Internet
Protocol (IP) host with its IP address and other related configuration information such as the subnet mask and
default gateway. RFCs 2131 and 2132 define DHCP as an Internet Engineering Task Force (IETF) standard based
on Bootstrap Protocol (BOOTP), a protocol with which DHCP shares many implementation details. DHCP allows
hosts to obtain necessary TCP/IP configuration information from a DHCP server.
The Microsoft Windows Server 2003 operating system includes a DHCP Server service, which is an optional
networking component. All Windows-based clients include the DHCP client as part of TCP/IP, including Windows
Server 2003, Microsoft Windows XP, Windows 2000, Windows NT 4.0, Windows Millennium Edition (Windows Me),
and Windows 98.
Note
 It is necessary to have an understanding of basic TCP/IP concepts, including a working knowledge of

subnets before you can fully understand DHCP. For more information about TCP/IP, see “TCP/IP Technical
Reference.”
Benefits of DHCP
In Windows Server 2003, the DHCP Server service provides the following benefits:
 Reliable IP address configuration. DHCP minimizes configuration errors caused by manual IP address
configuration, such as typographical errors, or address conflicts caused by the assignment of an IP
address to more than one computer at the same time.
 Reduced network administration. DHCP includes the following features to reduce network
administration:
 Centralized and automated TCP/IP configuration.
 The ability to define TCP/IP configurations from a central location.
 The ability to assign a full range of additional TCP/IP configuration values by means of DHCP
options.
 The efficient handling of IP address changes for clients that must be updated frequently, such as
those for portable computers that move to different locations on a wireless network.
 The forwarding of initial DHCP messages by using a DHCP relay agent, thus eliminating the need
to have a DHCP server on every subnet.
Why use DHCP

Every device on a TCP/IP-based network must have a unique unicast IP address to access the network and its
resources. Without DHCP, IP addresses must be configured manually for new computers or computers that are
moved from one subnet to another, and manually reclaimed for computers that are removed from the network.
DHCP enables this entire process to be automated and managed centrally. The DHCP server maintains a pool of IP
addresses and leases an address to any DHCP-enabled client when it starts up on the network. Because the IP
addresses are dynamic (leased) rather than static (permanently assigned), addresses no longer in use are
automatically returned to the pool for reallocation.
The network administrator establishes DHCP servers that maintain TCP/IP configuration information and provide
address configuration to DHCP-enabled clients in the form of a lease offer. The DHCP server stores the
configuration information in a database, which includes:
 Valid TCP/IP configuration parameters for all clients on the network.
 Valid IP addresses, maintained in a pool for assignment to clients, as well as excluded addresses.
 Reserved IP addresses associated with particular DHCP clients. This allows consistent assignment of a
single IP address to a single DHCP client.
 The lease duration, or the length of time for which the IP address can be used before a lease renewal is
required.
A DHCP-enabled client, upon accepting a lease offer, receives:
 A valid IP address for the subnet to which it is connecting.
 Requested DHCP options, which are additional parameters that a DHCP server is configured to assign to
clients. Some examples of DHCP options are Router (default gateway), DNS Servers, and DNS Domain
Name. For a full list of DHCP options, see “DHCP Tools and Settings.”
Terms and Definitions

The following table lists common terms associated with DHCP.
DHCP Terms and Definitions
Term Definition
DHCP server A computer running the DHCP Server service that holds information about available
IP addresses and related configuration information as defined by the DHCP
administrator and responds to requests from DHCP clients.
DHCP client A computer that gets its IP configuration information by using DHCP.
Scope A range of IP addresses that are available to be leased to DHCP clients by the DHCP
Server service.
Subnetting The process of partitioning a single TCP/IP network into a number of separate
network segments called subnets.
DHCP option Configuration parameters that a DHCP server assigns to clients. Most DHCP options
are predefined, based on optional parameters defined in Request for Comments
(RFC) 2132, although extended options can be added by vendors or users.
Option class An additional set of options that can be provided to a DHCP client based on its
computer class membership. The administrator can use option classes to
submanage option values provided to DHCP clients. There are two types of options
classes supported by a DHCP server running Windows Server 2003: vendor classes
and user classes.
Lease The length of time for which a DHCP client can use a DHCP-assigned IP address
configuration.
Reservation A specific IP address within a scope permanently set aside for leased use by a
specific DHCP client. Client reservations are made in the DHCP database using the
DHCP snap-in and are based on a unique client device identifier for each reserved
entry.
Exclusion/exclusion One or more IP addresses within a DHCP scope that are not allocated by the DHCP
range Server service. Exclusions ensure that the specified IP addresses will not be offered
to clients by the DHCP server as part of the general address pool.
DHCP relay agent Either a host or an IP router that listens for DHCP client messages being broadcast
on a subnet and then forwards those DHCP messages directly to a configured DHCP
server. The DHCP server sends DHCP response messages directly back to the DHCP
relay agent, which then forwards them to the DHCP client. The DHCP administrator
uses DHCP relay agents to centralize DHCP servers, avoiding the need for a DHCP
server on each subnet. Also referred to as a BOOTP relay agent.
Unauthorized DHCP A DHCP server that has not explicitly been authorized. Sometimes referred to as a
server rogue DHCP server.
In a Windows Server 2003 domain environment, the DHCP Server service on an
unauthorized server running Windows Server 2003 fails to initialize. The
administrator must explicitly authorize all DHCP servers running Windows
Server 2003 that operate in an Active Directory service domain environment. At
initialization time, the DHCP Server service in Windows Server 2003 checks for
authorization and stops itself if the server detects that it is in a domain environment
and the server has not been explicitly authorized.
Automatic Private IP A TCP/IP feature in Windows XP and Windows Server 2003 that automatically
Addressing (APIPA) configures a unique IP address from the range 169.254.0.1 through
169.254.255.254 with a subnet mask of 255.255.0.0 when the TCP/IP protocol is
configured for automatic addressing, the Automatic private IP address alternate
configuration setting is selected, and a DHCP server is not available. The APIPA
range of IP addresses is reserved by the Internet Assigned Numbers Authority
(IANA) for use on a single subnet, and IP addresses within this range are not used
on the Internet.
Superscope A configuration that allows a DHCP server to provide leases from more than one
scope to clients on a single physical network segment.
Multicast IP addresses Multicast IP addresses allow multiple clients to receive data that is sent to a single
IP address, enabling point-to-multipoint communication. This type of transmission
is often used for streaming media transmissions, such as video conferencing.
Multicast Scope A range of multicast IP addresses that can be assigned to DHCP clients. A multicast
scope allows dynamic allocation of multicast IP addresses for use on the network by
using the MADCAP protocol, as defined in RFC 2730.
BOOTP An older protocol with similar functionality; DHCP is based on BOOTP. BOOTP is an
established protocol standard used for configuring IP hosts. BOOTP was originally
designed to enable boot configuration for diskless workstations. Most DHCP servers,
including those running Windows Server 2003, can be configured to respond to both
BOOTP requests and DHCP requests.
DHCP Tools and Settings

2003 with SP2
DHCP Tools and Settings

In this section
 DHCP Tools
 DHCP Options
 Related information
DHCP Tools
The following tools are associated with DHCP.
DHCP Snap-in
The DHCP snap-in allows you to perform a variety of administrative tasks for your DHCP servers:
 Create and manage scopes, including superscopes and multicast scopes.
 Create and manage properties for scopes, such as options, reservations, and exclusion ranges.
 Review active leases for each scope.
Category
The DHCP snap-in Microsoft Management Console (MMC) appears as an administrative tool after you install DHCP
from Add/Remove Windows Components in Control Panel. The DHCP snap-in can also be added to Windows
Server 2003 or Windows XP by installing the Windows Server 2003 Administrative Tools Pack. This allows remote
administration of DHCP servers running Windows 2000 Server or Windows Server 2003 from a Windows XP-based
workstation.
Version Compatibility
The Windows Server 2003 DHCP snap-in is compatible with DHCP servers running Windows Server 2003 and
Windows 2000.
Netsh
Netsh is a command-line scripting tool that allows you to display or modify the network configuration of a
computer. Netsh also provides a scripting feature that allows you to run a group of commands in batch mode
against a specified computer. Netsh can also save a configuration script in a text file for archival purposes or for
reuse in configuring other servers.
Commands in the netsh dhcp context provide a command-line method to help with the administration of DHCP
servers and provides an equivalent alternative to console-based management. All commands in netshdhcp
context can also be executed against a specified remote server.
Category
Netsh is a command-line tool.
Version compatibility
You can use netsh commands with Windows 2000 Server and Windows Server 2003.
Network Monitor
You can use the Network Monitor tool or a commercial packet analyzer (also known as a network sniffer), to
capture and view packets such as DHCP messages.
In Windows 2000 Server and Windows Server 2003, Network Monitor is installed as an optional management and
monitoring component by using Add or Remove Programs in Control Panel. After it is installed, you can run
Network Monitor from the Administrative Tools folder.
Category
Network Monitor is available in Microsoft Systems Management Server or with Windows 2000 Server and Windows
Server 2003.
Version compatibility
You can use Network Monitor to capture and view packets in Windows XP, Windows 2000, or Windows
Server 2003.
DHCP Options
This section lists the predefined options available for use with the Microsoft Windows Server 2003 DHCP service.
These options are defined according to the updated standards reference for DHCP options in RFC 2132, “DHCP
Options and BOOTP Vendor Extensions.”
Use the DHCP Microsoft Management Console (MMC) snap-in to specifically configure each option value, and enable
the option for assignment and distribution to DHCP clients based on server, scope, class, or client-specific levels of
preference.
In this section:
 Basic options. These options were originally defined in RFC 1497 and relisted in RFC 2123.
 IP host options. These options affect the operation of the IP layer, on a per-host basis.
 IP interface options. These options affect operation of the IP layer on a per-interface basis.
 Link layer options. These options affect operation of the data-link layer on a per-interface basis.
 TCP options. These options affect operation of the TCP layer on a per-interface basis.
 Application layer options. These options affect the application layer operations on a per-interface basis.
 NetBIOS over TCP/IP options. These options are used to support NetBIOS over TCP/IP.
 Vendor-specific options. These options are specified for vendor class use..
 User class options. These options are specified for user class use.
 DHCP extensions. These options are used to implement default protocol interaction and system behavior
between servers and clients.
 Administrator-defined options. These options are not preconfigured in Windows Server 2003, but can
be defined by an administrator.
 Microsoft options. These options are only available for use with supported Microsoft DHCP clients, such
as computers running Windows Server 2003 or Windows XP.
Note
 For all DHCP options that use a list of IP addresses as the value data, the IP addresses are always used in
order of preference by the DHCP client. For example, the first address in the list is used first.
Basic Options
The following sections list the basic DHCP options originally defined in RFC 1497 and updated in RFC 2132, for use
with DHCP and the Boot Protocol (BOOTP) service. The BOOTP service refers to options as vendor extensions.
The DHCP service supports configuration and distribution of any options assigned using the DHCP Manager snap-in.
By default, Microsoft DHCP-enabled clients require and provide storage and interpretation for options 1 (Subnet
Mask), 3 (Router), 6 (DNS Servers), and 15 (DNS Domain Name).
Pad Option
A single octet of zero (“00”) used for padding. This option differs from most DHCP options in that it does not use a
length or value field. This option used to ensure that subsequent DHCP options are aligned on word boundaries the
same as they appear in the DHCP packet. This option does not require configuration.
Code
0
Length
Not used.
Value
Not used.
Structure of Pad Option
Code
End Option
A single octet of decimal 255 (“FF”) used to indicate the end of a DHCP options area in DHCP messages. This option
differs from most DHCP options because it does not use a length or value field. Typically, it is used at the end of
the options field to indicate that there is no more option data in a DHCP message. It can also be used within the
message, in connection with vendor-specific information (option 43), to indicate the end of an encapsulated
vendor-specific options subfield. This option does not require configuration.
Code
255
Length
Not used.
Value
Not used.
Structure of End Option
Code
255
Subnet Mask
This option specifies the subnet mask of the client subnet, as described in RFC 950. The value for this option is
taken from the Subnet Mask field, as defined in the DHCP ScopeProperties dialog box in DHCP Manager. A
DHCP client running Windows XP or Windows Server 2003 requests this option.
Code
1
Length
Fixed, 4 octets.
Value
Unsigned 32-bit (4 octet) integer representing the subnet mask for an IP address provided in a DHCP message.
Structure of Subnet Mask
Code Length Subnet Mask
1 4 subnet mask in binary format
Time Offset
This option specifies an offset value (in seconds) from the Coordinated Universal Time (UTC) that applies to the
client subnet. This value is configurable as a signed 32-bit integer. Positive offset values indicate a subnet location
east of the zero meridian. Negative offset values indicate a subnet location west of the zero meridian.
Code
2
Length
Fixed, 4 octets.
Value
Signed 32-bit integer used for offset of UTC.
Structure of Time Offset
Code Length Time Offset
2 4 time
Router
This option specifies a list of IP addresses for routers on the client subnet. When more than one router is assigned,
the client interprets and uses the addresses in the specified order. This option is normally used to assign a default
gateway to DHCP clients on a subnet. A DHCP client running Windows XP or Windows Server 2003 requests this
option.
Code
3
Length
Variable. Minimum length of 4 octets; octet length increases in multiples of 4 for each router address listed.
Value
Unsigned 32-bit integer representing the IP address of each assigned router.
Structure of Router
Code Length Address 1 Address N
3 n IP address in binary format IP address in binary format
Time Server
This option specifies a list of IP addresses for time servers, as defined in RFC 868, that are available to the client.
When more than one time server is assigned, the client interprets and uses the addresses in the specified order.
Code
4
Length
Variable. Minimum length of 4 octets; octet length increases in multiples of 4 for each time server address listed.
Value
Unsigned 32-bit integer representing the IP address of each assigned time server.
Structure of Time Server
IEN Name Server

This option specifies a list of IP addresses for Internet Engineering Note (IEN) name servers available to the client.
When more than one server is assigned, the client interprets and uses the addresses in the specified order.
Code
5
Length
Variable. Minimum length of 4 octets; octet length increases in multiples of 4 for each IEN name server address
listed.
Value
Unsigned 32-bit integer representing the IP address of each assigned IEN name server.
Structure of IEN Name Server

DNS Servers
This option specifies a list of IP addresses for DNS name servers available to the client. When more than one server
is assigned, the client interprets and uses the addresses in the specified order. A DHCP client running Windows XP
and Windows Server 2003 requests this option.
Code
6
Length
Variable. Minimum length of 4 octets; octet length increases in multiples of 4 for each Domain Name System (DNS)
server address listed.
Value
Unsigned 32-bit integer representing the IP address of each assigned DNS server.
Structure of DNS Servers
Log Server
This option specifies a list of IP addresses for Massachusetts Institute of Technology Lab for Computer Science
(MIT-LCS) User Datagram Protocol (UDP) log servers available to the client. When more than one server is
assigned, the client interprets and uses the addresses in the specified order.
Code
7
Length
Variable. Minimum length of 4 octets; octet length increases in multiples of 4 for each log server address listed.
Value
Unsigned 32-bit integer representing the IP address of each assigned log server.
Structure of Log Server
Cookie Server
This option specifies a list of IP addresses for cookie servers, as defined in RFC 865, available to the client. When
more than one server is assigned, the client interprets and uses the addresses in the specified order.
Code
8
Length
Variable. Minimum length of 4 octets; octet length increases in multiples of 4 for each cookie server address listed.
Value
Unsigned 32-bit integer representing the IP address of each assigned cookie server.
Structure of Cookie Server
LPR Server
This option specifies a list of IP addresses for line printer (LPR) servers, as defined in RFC 1179, available to the
client. When more than one server is assigned, the client interprets and uses the addresses in the specified order.
Code
9
Length
Variable. Minimum length of 4 octets; octet length increases in multiples of 4 for each LPR server address listed.
Value
Unsigned 32-bit integer representing the IP address of each assigned LPR server.
Structure of LPR Server
Impress Server
This option specifies a list of IP addresses for Imagen Impress servers available to the client. When more than one
server is assigned, the client interprets and uses the addresses in the specified order.
Code
10
Length
Variable. Minimum length of 4 octets; octet length increases in multiples of 4 for each Impress server address
listed.
Value
Unsigned 32-bit integer representing the IP address of each assigned Impress server.
Structure of Impress Server
Resource Location Server

This option specifies a list of IP addresses for resource location servers, as defined in RFC 887, available to the
client. When more than one server is assigned, the client interprets and uses the addresses in the specified order.
Code
11
Length
Variable. Minimum length of 4 octets; octet length increases in multiples of 4 for each resource location server
address listed.
Value
Unsigned 32-bit integer representing the IP address of each assigned resource location server.
Structure of Resource Location Server
Host Name
This option specifies a host name for the client. In some cases, this name can also be fully qualified by appending
the name value provided here with the DNS domain name, as specified in DHCP option 15. For Windows clients,
this option is not supported for use when configuring the client’s host name, which is set for computers running
Windows XP or Windows Server 2003 on the Computer Name tab in the System Properties dialog box on the
client computer.
Code
12
Length
Length varies depending on data in value. Minimum length is 1 octet. Maximum length is limited to 63 characters,
or one octet for each character used in the host name configured for use with this option.
Value
ASCII character text.
Structure of Host Name
Code Length Host Name
12 n name
Boot File Size

This option specifies the size of the default boot image file for the client.
Code
13
Length
Fixed, 2 octets.
Value
Unsigned 16-bit integer to indicate the number of 512-octet blocks needed to make up the boot file.
Structure of Boot File Size
Code Length File Size

13 02 16-bit integer
Merit Dump File

This option specifies the path name of a file to which the client’s core memory image should be dumped in the
event the client terminates abnormally. Data used for a value is in ASCII character text format. The length of the
value field depends on the number of characters used in the path specified. For example, if the path entered has
20 characters, the value field for this option should also be 20 octets in length.
Code
14
Length
Length varies depending on data in value. Minimum length is 1 octet.
Value
Structure of Merit Dump File
Code Length Dump File Path
14 n path name
DNS Domain Name

This option specifies the domain name that the DHCP client should use when resolving unqualified domain names
with the Domain Name System (DNS). For DHCP clients running Windows 2000, Windows XP, and Windows
Server 2003, the DNS Domain Name option becomes the connection-specific DNS name assigned to the DHCP-
configured interface. The connection-specific DNS name is used to construct fully qualified domain names (FQDNs)
that are registered using DNS dynamic update. The length of the value field depends on the number of characters
used in the DNS domain name specified. For example, if the domain name has 20 characters, the value field for
this option is 20 octets in length. A DHCP client running Windows XP or Windows Server 2003 requests this option.
Code
15
Length
Value
Structure of DNS Domain Name
Code Length Domain Name
15 n domain name
Swap Server
This option specifies the IP address of the client’s swap server.
Code
16
Length
Length is fixed at 4 octets.
Value
A single IP address for the client’s swap server (unsigned 32-bit integer).
Structure of Swap Server
Code Length Swap Server Address
16 4 IP address in binary format
Root Path
This option specifies the path of the client’s root disk. The path value is formatted as ASCII text. The length of the
value field depends on the number of characters used in the root path specified. For example, if the root path
entered has 20 characters, the value field for this option is 20 octets in length.
Code
17
Length
Value
Structure of Root Path
Code Length Root Disk Path
17 n path name
Extensions Path
This option specifies an extension path file that can be retrieved using Trivial File Transfer Protocol (TFTP). The file
contains information to be interpreted as the 64-octet vendor-extension field within a BOOTP response. To allow
more than 64 octets of BOOTP vendor extension information, this option can be enabled. When enabled, the length
of the specified extension path file is not constrained in size and all references in the extensions file to tag 18 (such
as instances of the BOOTP Extensions Path field) are ignored.
Code
18
Length
Value
Structure of Extension Path
Code Length Extensions Path

18 n file name
IP Host Options
The following sections describe the DHCP options that affect the operation of the IP layer, on a per-host basis.
IP Forwarding Enable/Disable
This option specifies whether the DHCP client should enable or disable forwarding of datagrams at the IP layer.
Code
19
Length
Length is fixed at 1 octet.
Value
Accepted values for this option are:
 1 = Enable IP forwarding
 0 = Disable IP forwarding
Structure of IP Forwarding Enable/Disable
Code Length Value
19 1 0 | 1
Non-Local Source Routing Enable/Disable

This option specifies whether the DHCP client enables or disables the forwarding at the IP layer of datagrams that
contain source routing information and were sent by a non-local host.
Code
20
Length
Length is fixed at 1 octet.
Value
 1 = Enable forwarding of datagrams from non-local sources
 0 = Disable forwarding of datagrams from non-local sources
Structure of Non-Local Source Routing Enable/Disable
Code Length Value
20 1 0 | 1
Policy Filter
This option specifies policy filters for non-local source routing on the client. The filters consist of a list of IP address
and mask pairs specifying destination and mask pairs for which incoming datagrams should be source-route
filtered. The client discards any source routed datagram with a next-hop address that does not match one of the
filters. For further information about policy filtering as it applies to this option, see RFC 1122 in the IETF RFC
Database.
Code
21
Length
Variable. Minimum length is 8 octets for a single destination and mask pair. Length increases in multiples of 8
octets for each additional pair used.
Value
Two consecutive, unsigned 32-bit integers indicating a paired value, consisting of an IP address followed by a
subnet mask.
Structure of Policy Filter
Code Length Address 1 Subnet Mask 1 Address N Subnet Mask N
21 n IP address in subnet mask in IP address in subnet mask in

binary format binary format binary format binary format
Maximum Datagram Reassembly Size

This option specifies the maximum size datagram that the client needs to be prepared to reassemble.
Code
22
Length
Fixed, 2 octets.
Value
Unsigned 16-bit integer specifying the maximum datagram size for reassembly. The minimum size for a datagram
is 576 octets.
Structure of Maximum Datagram Reassembly Size
Code Length File Size
22 2 16-bit integer
Default IP Time-To-Live
This option specifies the default Time-To-Live (TTL) that the client uses for the datagrams it sends.
Code
23
Length
Fixed, 1 octet.
Value
A number (in seconds) between 1 and 255.
Structure of Default IP Time-To-Live
Code Length TTL
23 1 TTL value in seconds
Path MTU Aging Time-out

This option specifies the time-out for aging Path Maximum Transmission Unit (MTU) values. Values are found by
the Path MTU discovery process, as defined in RFC 1191.
Code
24
Length
Fixed, 4 octets.
Value
A number (in seconds) that specifies a time-out value.
Structure of Path MTU Aging Time-out
Code Length Time-out
24 4 time-out value in seconds
Path MTU Plateau Table

This option specifies a table of MTU sizes to use when performing Path MTU discovery, as defined in RFC 1191.
Code
25
Length
Variable. Minimum length is 2 octets and increases in multiples of 2.
Value
A table formatted as a list of 16-bit unsigned integers, ordered from smallest to largest. The minimum tabled MTU
value cannot be smaller than 68.
Structure of Path MTU Plateau Table
Code Length MTU Size 1 MTU Size N
25 n MTU size in binary format MTU size in binary format
IP Interface Options
The following sections describe the DHCP options that affect operation of the IP layer on a per-interface basis.
Interface MTU
This option specifies the MTU size that can be used on a specified host adapter interface.
Code
26
Length
Fixed, 2 octets.
Value
A 16-bit unsigned integer specifying the interface MTU. The minimum value for the MTU is 68.
Structure of Interface MTU
Code Length MTU
26 2 interface MTU
All Subnets Are Local

This option specifies whether the client assumes that all subnets within the client’s internetwork use the same MTU
size as the local subnet on which the client is connected.
Code
27
Length
Fixed, 1 octet.
Value
 1 = Clients assume all subnets are local and share the same MTU size
 0 = Clients assume some subnets are not local and that smaller MTU sizes might be in use on remote
subnets
Structure of All Subnets Are Local
Code Length Value
27 1 0 | 1
Broadcast Address
This option specifies the broadcast address used on the client’s subnet.
Code
28
Length
Fixed, 4 octets.
Value
Typically, the limited broadcast IP address (255.255.255.255), but can be modified using legal values for broadcast
addresses, as specified in section 3.2.1.3 of RFC 1122.
Structure of Broadcast Address

Code Length Broadcast Address
28 4 broadcast address in binary format
Perform Mask Discovery

This option specifies whether the client uses Internet Control Message Protocol (ICMP) for subnet mask discovery.
Code
29
Length
Fixed, 1 octet.
Value
 1 = Client performs subnet mask discovery
 0 = Client does not perform subnet mask discovery
Structure of Perform Mask Discovery
Code Length Value
29 1 0 | 1
Mask Supplier
This option specifies whether the client responds to subnet mask requests using ICMP.
Code
30
Length
Fixed, 1 octet.
Value
 1 = Client responds to subnet mask requests
 0 = Client does not respond to subnet mask requests
Structure of Mask Supplier
Code Length Value
30 1 0 | 1
Perform Router Discovery

This option specifies whether the client solicits routers using the router discovery method in RFC 1256. A DHCP
client running Windows XP or Windows Server 2003 requests this option.
Code
31
Length
Fixed, 1 octet.
Value
 1 = Client performs router discovery
 0 = Client does not perform router discovery
Structure of Perform Router Discovery
Code Length Value
31 1 0 | 1
Router Solicitation Address

This option specifies the IP address to which the client submits router solicitation requests.
Code
32
Length
Fixed, 4 octets.
Value
Unsigned 32-bit integer representing an IP address.
Structure of Router Solicitation Address
Code Length Address
Static Routes
This option specifies a list of classful static routes that the DHCP client automatically adds to its IP routing table.
Multiple routes to the same destination are listed in descending order of priority. The default route of 0.0.0.0 is an
illegal destination for a static route. To configure the default route, use the Router DHCP option to assign a default
gateway. A DHCP client running Windows XP or Windows Server 2003 requests this option.
Code
33
Length
Variable. Minimum length of 8 octets; octet length increases in multiples of 8 for each additional static route
provided with this option.
Value
A list of IP address pairs. Each set of 8 octets provides two consecutive IP addresses pairing the destination (as a
classful network ID) and a router address (the IP address of the router interface on the subnet to which this scope-
specific option is configured) used for each route. The first 4 octets specify the destination classful network ID, and
the second 4 octets specify the router IP address.
Structure of Static Routes
Code Length Destination 1 Router 1 Destination N Router N
33 n IP address in IP address in IP address in IP address in

binary format binary format binary format binary format
Classless Static Route

This option specifies a list of classful static routes that the client automatically adds to its IP routing table. A DHCP
client running Windows XP or Windows Server 2003 requests this option. The Classless Static Route can be used to
configure split tunneling for remote access virtual private network (VPN) clients running Windows XP and Windows
Server 2003. For more information, see “VPN Technical Reference.”
Code
249
Note
 This is the same as option 121, as defined in RFC 3442.
Length
Variable. Minimum length of 5 octets; maximum octet length depends on the nature and number of the classless
static routes. Each route entry includes a destination descriptor and a router and can vary from a minimum of
5 octets in length to maximum 9 octets in length. For more information about how classless static routes are
constructed using a destination descriptor, see RFC 3442 in the IETF RFC Database.
Value
The destination descriptor and the router IP address. The value is encoded. For the encoding scheme, see RFC
3442.
Structure of Classless Static Route
Code Length Destination 1 Router 1 Destination N Router N
249 n Destination IP address Destination IP address

descriptor, as in binary descriptor, as in binary
defined in RFC format defined in RFC format
3442 3442
Link Layer Options

The following sections describe the DHCP options that affect operation of the data link layer on a per-interface
basis.
Trailer Encapsulation
This option specifies whether the client negotiates the use of trailers, as described in RFC 893, when using the
Address Resolution Protocol (ARP).
Code
34
Length
Fixed, 1 octet.
Value
 1 = Client attempts to use trailer
 0 = Client does not attempt to use trailers
Structure of Trailer Encapsulation
Code Length Value
34 1 0 | 1
ARP Cache Time-Out

This option specifies the time-out for ARP cache entries.
Code
35
Length
Fixed, 4 octets.
Value
An unsigned 32-bit integer specifying a time-out value, in seconds.
Structure of ARP Cache Time-Out
Code Length Time
35 4 time-out value in seconds
Ethernet Encapsulation
This option specifies whether the client uses Ethernet II (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation (if the
interface is Ethernet).
Code
36
Length
Fixed, 1 octet.
Value
 1 = Client uses RFC 1042 encapsulation
 0 = Client uses RFC 894 encapsulation
Structure of Ethernet Encapsulation

Code Length Value
36 1 0 | 1
TCP Options
The following sections describe the DHCP options that affect operation of the TCP layer on a per-interface basis.
TCP Default TTL

This option specifies the default TTL that the client uses when sending TCP segments.
Code
37
Length
Fixed, 1 octet.
Value
An unsigned 8-bit integer specifying a Time-To-Live (TTL) value in seconds. The minimum TTL value is 1.
Structure of TCP Default TTL
Code Length TTL
37 1 TTL value in seconds
TCP Keep-Alive Interval

This option specifies the interval the client waits before sending a keep-alive message on a TCP connection. A value
of 0 indicates that the client should not send keep-alive messages on connections unless specifically requested by
an application.
Code
38
Length
Fixed, 4 octets.
Value
An unsigned 32-bit integer that specifies a keep-alive interval, in seconds.
Structure of TCP Keep-Alive Interval
Code Length Time
38 4 keep-alive interval in seconds
TCP Keep-Alive Garbage

This option specifies whether or not the client sends TCP keep-alive messages with an octet of garbage data for
compatibility with older implementations.
Code
39
Length
Fixed, 1 octet.
Value
 1 = Client sends keep-alive garbage octet
 0 = Client does not send keep-alive garbage octet
Structure of TCP Keep-Alive Garbage
Code Length Value
39 1 0 | 1
Application Layer Options

The following sections describe the DHCP options that affect the application layer operations on a per-interface
basis. These are miscellaneous options used to configure programs and services.
NIS Domain Name

This option specifies the Network Information Service (NIS) domain name as an ASCII string.
Code
40
Length
Value
Structure of NIS Domain Name
Code Length NIS Domain Name
40 n NIS domain name
NIS Servers
This option lists the IP addresses in order of preference for Network Information Service (NIS) servers available to
the client.
Code
41
Length
Variable. Minimum length is 4 octets; octet length increases in multiples of 4 for each server address listed.
Value
Unsigned 32-bit integer representing the IP address of each NIS server.
Structure of NIS Servers

NTP Servers
This option lists the IP addresses in the order of preference for Network Time Protocol (NTP) servers available to
the client.
Code
42
Length
Value
Unsigned 32-bit integer representing the IP address of each NTP server.
Structure of NTP Servers
X Window System Font Servers

This option lists the IP addresses in the order of preference for X Window System font servers available to the
client.
Code
48
Length
Value
Unsigned 32-bit integer representing each server IP address.
Structure of X Window System Font Servers
X Window System Display Manager Servers

This option lists the IP addresses in the order of preference for X Window System display manager servers
available to the client.
Code
49
Length
Value
Unsigned 32-bit integer representing each server IP address.
Structure of X Window System Display Manager Servers
NIS+ Domain Name

This option specifies the name of the client’s Network Information Service Plus (NIS+) domain name as an ASCII
string.
Code
64
Length
Length varies depending on the data in its value. Minimum length is 1 octet.
Value
Structure of NIS+ Domain Name
Code Length NIS+ Domain Name
64 n NIS+ domain name
NIS+ Servers
This option lists the IP addresses in the order of preference for Network Information Service Plus (NIS+) servers
Code
65
Length
Value
Unsigned 32-bit integer representing IP address of NIS+ servers.
Structure of NIS+ Servers
Mobile IP Home Agents

This option lists the IP addresses in the order of preference for mobile IP home agents available to the client.
Code
68
Length
Variable. Minimum length is 0 octets. A length of 0 octets signifies that no mobile IP home agents are available.
Octet length increases in multiples of 4 for each mobile IP home agent address listed.
Value
Unsigned 32-bit integer representing IP address of a mobile IP home agent.
Structure of Mobile IP Home Agents
Simple Mail Transfer Protocol (SMTP) Server

This option lists the IP addresses in order of preference for SMTP servers available to the client.
Code
69
Length
Variable. Minimum length is 4 octets; octet length increases in multiples of 4 for each server IP address listed.
Value
Unsigned 32-bit integers representing IP addresses of servers.
Structure of Simple Mail Transfer Protocol (SMTP) Server
Post Office Protocol 3 (POP3) Server

This option lists the IP addresses in order of preference for POP3 servers available to the client.
Code
70
Length
Value
Structure of Post Office Protocol 3 (POP3) Server

Network News Transport Protocol Server
This option lists the IP addresses in order of preference for NNTP servers available to the client.
Code
71
Length
Value
Structure of Network News Transport Protocol Server
Default World Wide Web Server

This option lists the IP addresses in order of preference for default Web servers available to the client.
Code
72
Length
Value
Structure of Default World Wide Web Server
Default FFinger Server

This option lists the IP addresses in order of preference for default Finger servers available to the client.
Code
73
Length
Value
Structure of Default Finger Server

Default Internet Relay Chat Server

This option lists the IP addresses in order of preference for default IRC servers available to the client.
Code
74
Length
Value
Structure of Default Internet Relay Chat Server
StreetTalk Server
This option lists the IP addresses in order of preference for StreetTalk servers available to the client.
Code
75
Length
Value
Structure of StreetTalk Server
StreetTalk Directory Assistance Server

This option lists the IP addresses in order of preference for StreetTalk Directory Assistance (STDA) servers
Code
76
Length
Value
Structure of StreetTalk Directory Assistance Server
NetBIOS over TCP/IP Options

The following options are used to support NetBIOS over TCP/IP. All Microsoft-based DHCP clients and DHCP servers
can recognize and support the use of these options.
WINS/NBNS Servers
This option lists the IP addresses for NetBIOS name servers (NBNSes) on the network. In Windows, a Windows
Internet Name Service (WINS) server is an NBNS. A DHCP client running Windows XP or Windows Server 2003
requests this option.
Code
44
Length
Variable. Minimum length is 4 octets; length can be increased by multiples of 4 for each address listed.
Value
Each 4 octets in this field contains an NBNS server IP address, specified as an unsigned 32-bit integer.
Structure of WINS/NBNS Servers
NetBIOS over TCP/IP Datagram Distribution Server

This option lists the IP addresses for NetBIOS datagram distribution (NBDD) servers.
Code
45
Length
Variable. Minimum length is 4 octets; length can be increased only by multiples of 4.
Value
Each 4 octets in this field contains an NBDD server IP address, specified as an unsigned 32-bit integer.
Structure of NetBIOS over TCP/IP Datagram Distribution Server
NetBIOS over TCP/IP Node Type

Configures the client node type for NetBIOS over TCP/IP (NetBT) clients, as described in RFCs 1001and 1002. On
multihomed computers, the node type is assigned for the computer, not to individual network adapters. A DHCP
client running Windows XP or Windows Server 2003 requests this option.
Code
46
Length
Fixed, 1 octet.
Value
 1 = b-node
 2 = p-node
 4 = m-node
 8 = h-node
Structure of NetBIOS over TCP/IP Node Type
Code Length Value
46 1 1 | 2 | 4 | 8
NetBIOS over TCP/IP Scope ID

This option specifies a string representing the NetBIOS over TCP/IP scope ID for the client, as specified in
RFCs 1001 and 1002. On multihomed computers, the node type is assigned for the computer, not to individual
network adapters. A DHCP client running Windows XP or Windows Server 2003 requests this option. The use of
NetBIOS scope IDs is not recommended.
Code
47
Length
Variable. Minimum length is 1 octet. Octet length is equal to the number of characters used in NetBIOS scope ID.
Value
This option specifies the NetBIOS over TCP/IP scope identifier used by the client. The format used for these scope
IDs is described in RFCs 1001 and 1002. For character-set restrictions, see the RFCs.
Structure of NetBIOS over TCP/IP Scope ID
Code Length NetBIOS Scope
47 n scope identifier
Vendor-Specific Options
This section describes reserved DHCP options specified for vendor class use. The vendor-specific options are
specified in RFC 2132. Vendor classes can be used by the DHCP service and DHCP clients running Windows 2000,
Windows XP, and Windows Server 2003. For any other DHCP clients, default classes provided by the DHCP service
can be used to group and classify non-identifying clients at the DHCP server.
The Windows Server 2003 DHCP snap-in provides a default vendor class called DHCP Standard. This class can
be used to group and classify clients that do not identify a vendor class to the DHCP service.
Vendor-Specific Information
This option is used by clients and servers to exchange vendor-specific information. Servers not equipped to
interpret the information ignore it. Clients that expect but do not receive the information attempt to operate
without it.
In some cases, a vendor uses this option to send more than one information item; therefore, this option can serve
as a subfield for encapsulating vendor-specific options. When encapsulating options, DHCP servers maintain the
same syntax (the same sequence of code, length, and value fields) for each encapsulated option as it would
normally appear in the full standard options field. The following exceptions are for the encapsulated, vendor-
specific subfield:
 A “Magic cookie” field cannot be used.
 All standard option codes — other than the padding option (0) or the end option (255) — can be
redefined, but should conform to the code, length, value syntax sequence described in RFC 2131.
 If present, the end option (255) signifies the end of the encapsulated vendor options, but not the end of
the encapsulated vendor-specific subfield. If no end option is present, the end for the encapsulated
vendor-specific subfield is taken from its stated length. For more information, see RFC 2132 in the IETF
RFC Database.
Code
43
Length
Variable. Minimum length is 1 octet.
Value
An object of n octets (where n is equal to the length specified with this option). The definition of values stored for
this option is vendor specific, and values provided here are presumed to be interpreted by vendor-specific code on
DHCP clients and the DHCP server.
Structure of Vendor-Specific Information
Code Length Value
43 n vendor-specific information (which can include subfield bytes 1-n)
When this option uses an encapsulated vendor-specific subfield, the information bytes 1– n have the following
format.
Code Length Data Item
T1 n d1, d2, ...dn
T2 n d1, d2, dn
Vendor Class Identifier
Can be used by DHCP clients to identify their vendor type and configuration when communicating with DHCP
servers. Vendors can define their own specific identifier values, like conveying a particular hardware or operating
system configuration.
For Windows Server 2003, all computers that function either as DHCP servers or DHCP clients can use and support
this option. When vendor classes are used, the DHCP server responds to identifying clients by using option 43, the
reserved option for returning vendor-specific information to the client.
DHCP servers that do not automatically interpret this option are expected to ignore it. For earlier, Windows-based
clients and other clients that do not support this option, the DHCP service classifies these clients as part of the
default vendor class — the DHCP Standard option class — predefined for Windows-based DHCP servers.
Code
60
Length
Variable. Minimum is 1 octet; Length varies according to n (the number of octets used as an identifier).
Value
A value of n octets, which can be interpreted by DHCP servers that support vendor-specific classification of clients.
Structure of Vendor Class Identifier
Code Length Value
60 n vendor class identifier
User Class Options

This section describes reserved DHCP options specified for user classes. User classes can be used by the DHCP
service and DHCP-enabled client computers running Windows Server 2003. For other DHCP clients, default classes
provided by the DHCP service can be used to group and classify non-identifying clients at the DHCP server.
User Class Information

A DHCP client can use this option to identify the user class of which it is a member when communicating with the
DHCP server. The information contained in this option is a Network Virtual Terminal (NVT) ASCII text object that
represents the user class ID.
You can use the DHCP snap-in to define specific user classes. When user classes are created, each class sets an
identifying string of information to be used by the DHCP service to classify identifying clients. Also, a default user
class is created for classifying clients that are unable to support a user class ID.
User classes can be helpful for separating client computers that have a shared or common need for similar software
configuration or user preferences. For example, an identifier can specify that a particular DHCP client be a member
of the class “accounting auditors,” who have special service needs, such as a particular database server.
Computers running Windows Server 2003 support sending or using this option. Legacy DHCP clients do not send a
class ID and cannot recognize DHCP user class IDs. Such client’s are assigned to the Default User Class, a user
class predefined for immediate use in the DHCP snap-in. Other user classes must be manually created.
Code
77
Length
Variable. Minimum is 2 octets.
Value
Structure of User Class Information
Code Length User Class Information
77 n c1, c2, c3, c4 ...cn
DHCP Extensions
The following options are specific to DHCP and are used to implement default protocol interaction and system
behavior between servers and clients. Some of these options are implicitly set when you configure server and
scope properties using the DHCP snap-in.
Requested IP Address
This option can be used by clients when sending a DHCPDiscover message to request a specific IP address from the
DHCP server.
Code
50
Length
Fixed, 4 octets.
Value
Single, unsigned 32-bit integer representing a requested IP address.
Structure of Requested IP Address
Code Length Requested IP Address
IP Address Lease Time

This option is used to negotiate and exchange lease-time information between DHCP clients and servers in two
possible ways. First, the option can be used in a DHCPDiscover or DHCPRequest message sent by a client to
request a lease time for its IP address. Second, the option can be used in a DHCPOffer message sent by a server to
specify a lease time for the client. This option is configured on the Scope Properties dialog box.
Code
51
Length
Fixed, 4 octets.
Value
Single, unsigned 32-bit integer representing a clients lease time (in seconds).
Structure of IP Address Lease Time
Code Length Lease Time

51 4 lease time in seconds
Option Overload
Used in messages sent by a DHCP server to indicate that either of the standard message fields in a DHCP packet
for server_host_name (sname) and boot_file_name (file) can be used to hold options (a condition
also known as overloaded).
When this option is used, it extends the options area in each packet by indicating that unused space for one or
both of these two standard fields should be allocated to the area used to carry DHCP options.
Code
52
Length
Fixed, 1 octet.
Value
Accepted values for this option include:
 1 = File field is overloaded
 2 = Sname field is overloaded
 3 = Both file and sname fields are overloaded
Structure of Option Overload
Code Length Value
52 1 1 | 2 | 3
TFTP Server Name

This option specifies the host name of the Trivial File Transfer Protocol (TFTP) server when the
server_host_name (sname) field in a DHCP message is overloaded and used for carrying additional DHCP
options.
Code
66
Length
Variable depending on data in value. Minimum length is 1 octet.
Value
Structure of TFTP Server Name
Code Length TFTP Server
66 n TFTP server host name

Boot File Name
This option specifies the name of a boot image file on the TFTP server when the boot_file_name (file) field in
a DHCP message is overloaded and used for carrying additional DHCP options.
Code
67
Length
Variable depending on data in value. Minimum length is 1 octet.
Value
Structure of Boot File Name
Code Length Boot File Name
67 n boot image file name
DHCP Message Type

This option is required for use in all DHCP messages to convey the type of message being sent.
Code
53
Length
Fixed, 1 octet.
Value
 1 = DHCP Discover message (DHCPDiscover)
 2 = DHCP Offer message (DHCPOffer)
 3 = DHCP Request message (DHCPRequest)
 4 = DHCP Decline message (DHCPDecline)
 5 = DHCP Acknowledgment message (DHCPAck)
 6 = DHCP Negative Acknowledgment message (DHCPNak)
 7 = DHCP Release message (DHCPRelease)
 8 = DHCP Informational message (DHCPInform)
Structure of DHCP Message Type
Code Length Value

53 1 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Server Identifier
This option is used in DHCPOffer and DHCPRequest messages, and might appear in DHCP Acknowledgment
messages (DHCPAck, DHCPNak). The server identifier is the IP address of a selected DHCP server.
This option is used in three possible ways. First, servers include this option in DHCPOffer messages so that clients
can distinguish between multiple lease offers. Second, clients include this option in DHCPRequest messages to
select a lease and indicate which offer is accepted from multiple lease offers. Third, clients can use the contents of
this option for unicast transmission of DHCPRequest messages to specific DHCP servers to renew a current lease.
Code
54
Length
Fixed, 4 octets.
Value
A single, unsigned 32-bit integer representing the IP address that identifies the DHCP server.
Structure of Server Identifier
Code Length Address
Parameter Request List

Used by a DHCP client to request specific option values from the DHCP server. Each option is requested and listed
by a single octet value containing a valid or recognized DHCP option Code for the server.
For clients that use this option, the list can be ordered by preference. Although the DHCP server is not required to
return options in the order they are requested it does attempt to insert the requested options in the requested
order.
Code
55
Length
Variable. Minimum of 1 octet; length increases by 1 octet for each option code included in the request list.
Value
List of 8-bit values, each representing an option code between 0 and 255.
Structure of Parameter Request List
Code Length Option Codes
55 n c1, c2...cn
Optional Message
Can be used by both the DHCP server and DHCP clients in the following ways:
 A server can use this option to provide and embed an error message in a DHCP Negative Acknowledgment
(DHCPNak) message in the event of a failure.
 A client can use this option in a DHCPDecline message to indicate why it declined offered parameters.
The message consists of a variable-length ASCII text string, which the receiving computer can then either log or
display.
Code
56
Length
Minimum of 1 octet. Length depends on the length of the sent message.
Value
Structure of Optional Message
Code Length Text
56 n c1, c2...cn
Maximum Message Size

Used by client to specify the maximum length for a DHCP message it can accept. A client can include this option in
DHCPDiscover or DHCPRequest messages; however, it does not include this option in DHCPDecline messages.
Code
57
Length
Fixed, 2 octets.
Value
A 16-bit integer indicating the maximum size, in octets, for a DHCP message. The minimum value for this option is
576.
Structure of Maximum Message Size
Code Length Value
57 2 maximum size
Renewal Time Value (T1)

The time value of this option is typically 50 percent of the client’s lease time. To adjust the value, change the
length of the client lease in the client scope properties or the per-user class on the DHCP server. You can also
change the value by using the Netsh tool.
Code
58
Length
Fixed, 4 octets.
Value
A 32-bit unsigned integer indicating the number of seconds before the client begins to renew its address lease with
the DHCP server.
Structure of Renewal Time Value (T1)
Code Length T1 Interval
58 4 renewal interval in seconds
Rebinding Time Value (T2)

The time value of this option is typically 87.5 percent of the full configured duration (lease time) for a client’s lease.
To adjust the value, change the length of the client lease in the properties for the client’s scope or per-user class
on the DHCP server. You can also change the value by using the Netsh tool.
Code
59
Length
Fixed, 4 octets.
Value
A 32-bit unsigned integer indicating the number of seconds before the client enters the rebinding state (if it has not
renewed its current address lease with the DHCP server).
Structure of Rebinding Time Value (T2)
Code Length T2 Interval
59 4 rebinding interval in seconds
Client Unique Identifier

This option is used by clients to specify their unique identifier to the server. This option is most useful for reserved
clients. When a reserved client contacts the server, the DHCP service checks and matches the client identifier value
to a corresponding identifier used to configure an address reservation in the server’s database. When a matching
reservation is found, the DHCP server returns the reserved address and its related parameters to the correct client.
Each clients identifier must be unique among all other client identifiers used on the DHCP client’s local subnet and
any remote subnets reachable using DHCP relay. Vendors and system administrators are responsible for choosing
client identifiers that meet this requirement for uniqueness. One way to ensure unique values is to use the client’s
media access control (MAC) address as the client identifier value. Media access control addresses are encoded in
the client’s network adapter hardware, and are assigned to hardware manufacturers in such a way as to ensure
that they are unique for each device.
Code
61
Length
Variable length; minimum length is 2 octets.
Value
A series of 2 or more octets treated as a single value by the DHCP server. Servers can interpret and use this value
to uniquely identify clients. The client identifier can consist of type-value pairs similar to the DHCP Header fields
“htype” and “chaddr,” which are defined by the DHCP protocol.
Structure of Client Unique Identifier
Code Length Type Client Identifier
61 n t1 i1, i2...in
Administrator-Defined Options
This section describes DHCP options that are reserved and specified for use by RFC 2132, but are not predefined
for use in the DHCP snap-in. Administrators can add these options to support DHCP clients that recognize these
options.
Proxy Autodiscovery for Internet Explorer 5

This option points to the configuration file that the client uses for automatic configuration of Internet Explorer 5. x
and Internet Explorer 6. The configuration file can be a .pac, .jvs, .js, or .ins file created by a system or Web
administrator when deploying Internet Explorer 5.x on an intranet. It might include settings for other Internet
Explorer configurable options, such as which home page to use, or settings for locating and using a proxy server.
The option is communicated between Internet Explorer client computers and the DHCP server using the
DHCPInform message. DHCPInform is currently supported for DHCP servers running Windows Server 2003 and
DHCP clients running Windows 2000, Windows XP, and Windows Server 2003.
The use of additional DHCP configuration is supported by Internet Explorer 5. x and Internet Explorer 6, but not
earlier versions, because those use different methods for automatic detection and configuration of proxy server
settings.
You can add and configure an alias (CNAME) resource record at the DNS server to support Internet Explorer proxy
server auto-discovery and configuration features.
Code
252
Length
Variable
Value
A URL that points to the configuration file that the client should use for automatic configuration of Internet Explorer
5.x and Internet Explorer 6.
Structure of Proxy Autodiscovery for Internet Explorer 5
Code Length Value
252 n URL name
Microsoft Options
This section describes reserved DHCP options defined by Microsoft. These options are only available for use with
supported Windows-based DHCP clients, such as computers running Windows Server 2003.
The Microsoft options are provided as encapsulated vendor-specific data fields within the vendor-specific
information option.
Currently, administrators can assign these options are by using the DHCP snap-in through the following vendor
classes: Microsoft options and Microsoft Windows 2000 options.
Disable NetBIOS over TCP/IP (NetBT)

This option can be used to selectively enable or disable NetBT for DHCP-enabled computers running Windows
Server 2003, Windows XP, and Windows 2000. By default, if this option is not present, Windows Server 2003,
Windows XP, and Windows 2000 enable the use of NetBT for network connections that are configured to use
TCP/IP. Earlier Windows-based clients require NetBT and do not support this option.
Code
1
Length
4 octets
Value
 1= NetBT remains enabled
 2=Disable NetBT for DHCP clients
Structure of Disable NetBIOS over TCP/IP (NetBT)
Code Length NetBT
001 4 1 | 2
Release DHCP Lease on Shutdown

This option can be used to control whether DHCP-enabled computers running Windows 2000, Windows XP, or
Windows Server 2003 sends a DHCPRelease message to the DHCP server when a shutdown occurs. It is actually
implemented and interpreted as a bit-masked value by the DHCP Client service. By default, these clients do not
send DHCPRelease messages on proper shutdown.
Code
2
Length
4 octets
Value
 1 = DHCP clients send a DHCPRelease message on proper shutdown
 0 = DHCP clients do not send a DHCPRelease message on proper shutdown
Structure of Release DHCP Lease on Shutdown

Code Length Release
002 4 0 | 1
Default Router Metric Base

This option can be used to set the default base metric for DHCP clients running Windows Server 2003. When this
option is set, the DHCP Client service uses the value configured here as the base metric for its default gateways.
Code
3
Length
4 octets
Value
This value represents a specified router metric base to be used for all default gateway routes used by DHCP-
enabled clients running Windows Server 2003. This value can be assigned as an integer representing a cost metric
ranging from 1 through 9,999. It is used in calculating the fastest, most reliable, and least expensive routes. If a
value is not specified, a default of either one (1) or the currently set interface-specific metric is used.
Structure of Default Router Metric Base
How DHCP Technology Works

2003 with SP2
How DHCP Works

DHCP provides an automated way to distribute and update IP addresses and other configuration information on a
network. A DHCP server provides this information to a DHCP client through the exchange of a series of messages,
known as the DHCP conversation or the DHCP transaction. If the DHCP server and DHCP clients are located on
different subnets, a DHCP relay agent is used to facilitate the conversation.
Note
 It is necessary to have an understanding of basic TCP/IP concepts, including working knowledge of

subnets before you can have a full understanding of DHCP. For more information about TCP/IP, see
“TCP/IP Technical Reference.”
In this section
 DHCP Architecture
 DHCP Protocols
 DHCP Processes and Interactions
DHCP Architecture
The DHCP architecture consists of DHCP clients, DHCP servers, and DHCP relay agents on a network. The clients
interact with servers using DHCP messages in a DHCP conversation to obtain and renew IP address leases.
DHCP Client Functionality
A DHCP client is any network-enabled device that supports the ability to communicate with a DHCP server in
compliance with RFC 2131, for the purpose of obtaining dynamic leased IP configuration and related optional
information.
DHCP provides support for client computers running any of the following Microsoft operating systems:
 Windows NT version 4.0
 Windows 2000
 Windows XP
 Windows Server 2003
 Windows 98
 Windows Millennium Edition
Automatic IP Configuration
DHCP supports Automatic Private IP Addressing (APIPA), which enables computers running Windows 2000,
Windows XP, and Windows Server 2003 to configure an IP address and subnet mask if a DHCP server is unavailable
at system startup and the Automatic private IP address Alternate Configuration setting is selected. This feature
is useful for clients on small private networks, such as a small-business office or a home office.
The DHCP Client service on a computer running Windows XP and Windows Server 2003 uses the following process
to auto-configure the client:
1. The DHCP client attempts to locate a DHCP server and obtain an IP address and configuration.
2. If a DHCP server cannot be found or does not respond after one minute, the DHCP client checks the
settings on the Alternate Configuration tab of the properties of the TCP/IP protocol.
If Automatic private IP address is selected, the DHCP client auto-configures its IP address and subnet
mask by using a selected address from the Microsoft-reserved Class B network, 169.254.0.0, with the
subnet mask 255.255.0.0. The DHCP client tests for an address conflict to ensure that the IP address is
not in use on the network. If a conflict is found, the client selects another IP address. The client retries
auto-configuration up to 10 times.
If User Configured is selected, the DHCP client configures a static IP address configuration. The DHCP
client tests for an address conflict to ensure that the IP address is not already in use on the network. If a
conflict is found, the DHCP client indicates the error condition to the user.
3. When the DHCP client succeeds in self-selecting an address, it configures its network interface with the IP
address. The client then continues to check for a DHCP server in the background every five minutes. If a
DHCP server responds, the DHCP client abandons its self-selected IP address and uses the address offered
by the DHCP server (and any other DHCP option information that the server provides) to update its IP
configuration settings.
If the DHCP client obtained a lease from a DHCP server on a previous occasion, and the lease is still valid (not
expired) at system startup, the client tries to renew its lease. If, during the renewal attempt, the client fails to
locate any DHCP server, it attempts to ping the default gateway listed in the lease, and proceeds in one of the
following ways:
 If the ping is successful, the DHCP client assumes that it is still located on the same network where it
obtained its current lease, and continues to use the lease as long as the lease is still valid. By default the
client then attempts, in the background, to renew its lease when 50 percent of its assigned lease time has
expired.
 If the ping fails, the DHCP client assumes that it has been moved to a network where a DHCP server is not
available. The client then auto-configures its IP address by using the settings on the Alternate
Configuration tab. When the client is auto-configured, it attempts to locate a DHCP server and obtain a
lease every five minutes.
Local Storage
Windows Server 2003 DHCP supports local storage, which allows clients to store DHCP information on their own
hard disks. Local storage is useful because it enables the client to store its last leased IP address, so that when the
client starts it first attempts to renew the lease of its previous IP address. Local storage also enables a client to be
shut down and restarted and it will use its previously leased address and configuration, even if the DHCP server is
unreachable or offline at the time that the client computer is restarted.
DHCP Server Responsibilities

The DHCP servers maintain scopes, reservations, and options as set by the administrator.
Scopes
A scope must be properly defined and activated before DHCP clients can use the DHCP server for automatic TCP/IP
configuration. A DHCP scope is an administrative collection of IP addresses and TCP/IP configuration parameters
that are available for lease to DHCP clients of a specific subnet. The network administrator creates a scope for each
subnet.
A scope has the following properties:
 A scope name, assigned when the scope is created.
 A range of possible IP addresses from which to include or exclude addresses used in DHCP lease offers.
 A unique subnet mask, which determines the network ID for an IP address in the scope.
 Lease duration values.
Each DHCP scope can have a single continuous range of IP addresses. To use several address ranges within a
single scope you must first define the entire address range for the scope, and then set exclusion ranges.
Lease Durations
When a scope is created, the lease duration is set to eight days by default. However there are situations when the
administrator might want to change the lease duration. The following are examples of adjusting the lease duration
due to individual network consideration:
 An organization has a large number of IP addresses available and configurations that rarely change. The
administrator increases the lease duration to reduce the frequency of lease renewal exchanges between
clients and the DHCP server. Because the DHCP clients are renewing their leases less frequently, DHCP-
related network traffic is reduced.
 A limited number of IP addresses are available and client configurations change frequently or clients move
often in or out of the network. The administrator reduces the lease duration. This increases the rate at
which unused addresses are returned to the available address pool for reassignment.
For example, consider the ratio between connected computers and available IP addresses. If 40 computers share
254 available addresses, the demand for reusing addresses is low. A long lease time, such as a few months, might
be appropriate in such a situation. However, if 230 computers must share the same address pool, demand for
available addresses is greater, and a shorter lease time, for example a few days, is more appropriate.
Note
 Although it is possible to configure a client with infinite lease duration, use infinite lease durations with
caution. Even relatively stable environments have a certain amount of client turnover. At a minimum,
computers might be added and removed, moved from one office to another, or network adapters might be
replaced. If a client with an infinite lease is removed from the network without releasing its lease, the
DHCP server is not notified, and the IP address is not automatically reused. Also, when using an infinite
lease, options set on the DHCP server are not automatically updated on the DHCP client, because the
client is never required to renew its lease and obtain the new options. It is recommended that
reservations be used rather than infinite lease durations.
Exclusion Ranges
When you create a new scope, immediately exclude the addresses of existing statically configured computers from
the scope. By using exclusion ranges, you can exclude specific IP address ranges within a scope so that those
addresses are not offered to clients. Assign IP addresses within exclusion ranges to computers or devices that must
have a static IP address, such as servers, firewalls, or routers.
You can use excluded IP addresses on your network by manually configuring these addresses at computers that do
not use DHCP to obtain an address, or by configuring reservations for these addresses.
Reservations
You can reserve IP addresses for assignment to specified computers or devices on the network. Reservations
ensure that a specified hardware device on a subnet always receives the same IP address lease. Use reservations
for DHCP-enabled devices that must always have the same IP address on your network, such as servers that do
not support Domain Name System (DNS) dynamic update.
Note
 If multiple DHCP servers are each configured with scopes that cover addresses that must be reserved, the
reservations must be specified on each DHCP server. Otherwise, the client might receive an IP address
from one of the DHCP servers that does not contain the reservation, and therefore might not receive the
IP address reserved for the client.
Superscopes
A superscope allows a DHCP server to provide leases from more than one scope to clients on a single physical
subnet. Before you can create a superscope, you must use the DHCP Microsoft Management Console (MMC) snap-
in to define at least one of the scopes to be included in the superscope. Scopes added to a superscope are called
member scopes. Superscopes can resolve DHCP Server service issues in several different ways; these issues
include situations in which:
 Support is needed for DHCP clients on a single physical network segment — such as a single Ethernet LAN
segment — where multiple logical IP networks are used. When more than one logical IP network is used
on a physical network, these configurations are also known as multinets. In a situation where
multinets are used, clients might not be able to communicate directly with each other, because the clients
might be on different logical subnets, even if they are on the same physical network segment. In this
case, routing must be enabled to allow the clients to communicate with each other. Also, a router or
BOOTP/DHCP relay agent must be configured on the subnet to allow DHCP messages to travel between
the logical subnets.
 Support is needed for DHCP clients that are in a multinet located on the other side of BOOTP relay agents.
 Clients need to be migrated to a new scope.
Interactions between Client and Server

DHCP servers and DHCP clients communicate through a series of DHCP messages. To obtain a lease, the DHCP
client initiates a conversation with a DHCP server using a series of these DHCP messages.
DHCP Messages
The following list includes the eight types of messages that can be sent between DHCP clients and servers. For
more information about the structure and specifics of each of these packets, see “DHCP Message Format” later in
this section.
DHCPDiscover
Broadcast by a DHCP client when it first attempts to connect to the network. The DHCPDiscover message requests
IP address information from a DHCP server.
DHCPOffer
Broadcast by each DHCP server that receives the client DHCPDiscover message and has an IP address
configuration to offer to the client. The DHCPOffer message contains an unleased IP address and additional TCP/IP
configuration information, such as the subnet mask and default gateway. More than one DHCP server can respond
with a DHCPOffer message. The client accepts the best offer, which for a Windows DHCP client is the first
DHCPOffer message that it receives.
DHCPRequest
Broadcast by a DHCP client after it selects a DHCPOffer. The DHCPRequest message contains the IP address from
the DHCPOffer that it selected. If the client is renewing or rebinding to a previous lease, this packet might be
unicast directly to the server.
DHCPAck
Broadcast by a DHCP server to a DHCP client acknowledging the DHCPRequest message. At this time, the server
also forwards any options. Upon receipt of the DHCPAck, the client can use the leased IP address to participate in
the TCP/IP network and complete its system startup. This message is typically broadcast, because the DHCP client
does not officially have an IP address that it can use at this point. If the DHCPAck is in response to a DHCPInform,
then the message is unicast directly to the host that sent the DHCPInform message.
DHCPNack
Broadcast by a DHCP server to a DHCP client denying the client’s DHCPRequest message. This might occur if the
requested address is incorrect because the client moved to a new subnet or because the DHCP client’s lease has
expired and cannot be renewed.
DHCPDecline
Broadcast by a DHCP client to a DHCP server, informing the server that the offered IP address is declined because
it appears to be in use by another computer.
DHCPRelease
Sent by a DHCP client to a DHCP server, relinquishing an IP address and canceling the remaining lease. This is
unicast to the server that provided the lease.
DHCPInform
Sent from a DHCP client to a DHCP server, asking only for additional local configuration parameters; the client
already has a configured IP address. This message type is also used by DHCP servers running Windows
Server 2003 to detect unauthorized DHCP servers.
DHCP Lease Process

A DHCP-enabled client obtains a lease for an IP address from a DHCP server. Before the lease expires, the DHCP
client must renew the lease or obtain a new lease. Leases are retained in the DHCP server database for a period of
time after expiration. By default, this grace period is four hours and cleanup occurs once an hour for a DHCP server
running Windows Server 2003. This protects a clients lease in case the client and server are in different time
zones, the internal clocks of the client and server computers are not synchronized, or the client is off the network
when the lease expires.
Obtaining a New Lease

A DHCP client initiates a conversation with a DHCP server when it is seeking a new lease, renewing a lease,
rebinding, or restarting. The DHCP conversation consists of a series of DHCP messages passed between the DHCP
client and DHCP servers. The following figure shows an overview of this process when the DHCP server and DHCP
client are on the same subnet.
DHCP Lease Process Overview
1. The DHCP client requests an IP address by broadcasting a DHCPDiscover message to the local subnet.
2. The client is offered an address when a DHCP server responds with a DHCPOffer message containing an IP
address and configuration information for lease to the client. If no DHCP server responds to the client
request, the client sends DHCPDiscover messages at intervals of 0, 4, 8, 16, and 32 seconds, plus a
random interval of between -1 second and 1 second. If there is no response from a DHCP server after one
minute, the client can proceed in one of two ways:
 If the client is using the Automatic Private IP Addressing (APIPA) alternate configuration, the
client self-configures an IP address for its interface.
 If the client does not support alternate configuration, such as APIPA, or if IP auto-configuration
has been disabled, the client network initialization fails.
In both cases, the client begins a new cycle of DHCPDiscover messages in the background every five
minutes, using the same intervals as before (0, 4, 8, 16, and 32 seconds), until it receives a DHCPOffer
message from a DHCP server.
3. The client indicates acceptance of the offer by selecting the offered address and broadcasting a
DHCPRequest message in response.
4. The client is assigned the address and the DHCP server broadcasts a DHCPAck message in response,
finalizing the terms of the lease.
When the client receives acknowledgment, it configures its TCP/IP properties by using the DHCP option information
in the reply, and completes its initialization of TCP/IP.
In rare cases, a DHCP server might return a negative acknowledgment to the client. This can happen if a client
requests an invalid or duplicate address. If a client receives a negative acknowledgment (DHCPNack), the client
must begin the entire lease process again.
When the DHCP client and the DHCP server are on the same IP broadcast subnet, the DHCPDiscover, DHCPOffer,
DHCPRequest, and DHCPAck messages are sent to identify clients by means of IP-level broadcasts sent to the
limited broadcast address and the media access control (MAC) broadcast address.
When the DHCP server and DHCP client are not on the same subnet either a router or a host on the DHCP client’s
subnet must act as a DHCP relay agent to support the forwarding of DHCP messages between the DHCP client and
the DHCP server.
Renewing a Lease
The DHCP client first attempts to renew its lease when 50 percent of the original lease time, known as T1, has
passed. At this point the DHCP client sends a unicast DHCPRequest message to the DHCP server that originally
granted its lease. If the server is available, and the lease is still available, the server responds with a unicast
DHCPAck message and the lease is renewed.
If the original DHCP server is available, but the client’s current lease is no longer available, the DHCP server
responds with a DHCPNack message, and the client immediately starts the process to obtain a new lease. This can
happen if the client has changed subnets or if the DHCP server cannot fulfill the lease request for some other
reason.
If there is no response from the DHCP server, the client waits until 87.5 percent of the lease time has passed
(known as T2). At T2, the client enters the rebinding state, and broadcasts a DHCPRequest message to attempt to
renew the lease from any available DHCP server. If no DHCP server is available by the time the lease expires, the
client immediately unbinds itself from the existing lease and starts the process to obtain a new lease, beginning
with a DHCPDiscover message.
Preventing Address Conflicts

Windows Server 2003 DHCP has both server-side and client-side conflict detection to prevent duplicate IP
addresses on your network.
Client Conflict Detection

Client computers running Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0, Windows
Millennium Edition, and Windows 98 automatically check to determine if an IP address is already in use before
using it.
After the DHCP client receives a lease from the DHCP server, the client sends an Address Resolution Protocol (ARP)
request to the address that it has been assigned. If a reply to the ARP request is received, the client has detected a
conflict and sends a DHCPDecline message to the DHCP server. The DHCP server attaches a BAD_ADDRESS value
to the IP address in the scope for the length of the lease. The client then begins the lease process again, and is
offered the next available address in the scope.
Note
 ARP requests do not traverse routers. Clients use ARP requests rather than pings (ICMP Echo messages)
because pings require the sender to have an IP address.
Server Conflict Detection

If your network includes older DHCP clients that do not perform conflict detection themselves, you can enable
conflict detection on the DHCP server. By default, the Windows Server 2003 DHCP Server service does not perform
any conflict detection.
To detect conflicts, the DHCP server pings (sends an ICMP Echo message to) an IP address before offering that
address to clients in a new lease. The DHCP server only pings addresses that have not been successfully and
previously leased. If a client requests a lease on an IP address that it already had or is requesting a renewal, the
DHCP server does not ping the IP address.
If conflict detection is enabled, an administrator-defined number of pings are sent. The server waits 1 second for a
reply. Because the time required for a client to obtain a lease is equal to the number of pings used, choose this
value carefully because it directly impacts the overall performance of the server. In general, one ping is sufficient.
If a response to the ping is received, a conflict is registered and that address is not offered to clients requesting a
lease from the server. The DHCP server then attaches a BAD_ADDRESS value to that IP address in the scope. The
DHCP server then tries to lease the next available address. If the duplicate address is removed from the network,
the BAD_ADDRESS value attached to the IP address can be deleted from the scope’s list of active leases, and then
the address returns to the pool. Addresses are marked as BAD_ADDRESS for the length of the lease for which the
scope is configured. If the BAD_ADDRESS entry is not manually removed, it will automatically be removed after a
period of time equal to the lease time for the scope.
Note
 In general, use server conflict detection only as a troubleshooting aid when you suspect that duplicate IP
addresses are in use on your network. Each additional conflict detection attempt adds to the time needed
to negotiate leases for DHCP clients.
DHCP Options
DHCP options are additional configuration parameters that a DHCP server assigns to clients. Options can also
be used for DHCP communication between the server computer and client computers.
The most specific options take precedence over the least specific options. This simplifies DHCP management and
allows a flexible administration that can range from per-server default settings to common settings for a specific
subnet and individualized client settings when needed for special circumstances. In most cases, the option values
are specified in the Options dialog box on the DHCP server, scope, or reservation.
DHCP options can be configured for specific values and enabled for assignment and distribution to DHCP clients
based on:
 Server options. These options apply globally for all scopes and classes defined at each DHCP server and
any clients that it services. Configured server option values always apply unless they are overridden by
options assigned to other scope, class, or client reservation.
 Scope options. These options apply to any clients that obtain a lease within that particular scope.
Configured scope option values always apply to all computers obtaining a lease in a given scope unless
they are overridden by options assigned to class or client reservation.
 Class options. These options apply to any clients that specify that particular DHCP Class ID value when
obtaining a scope lease. Configured class option values always apply to all computers configured as
members in a specified DHCP option class unless they are overridden by options assigned to a client
reservation.
 Reserved client options. These options apply only to the client corresponding to the reservation.
Reserved client option values override all other server, scope, or class assigned option values.
Options are typically applied at each DHCP server at the server or scope level. To precisely manage or customize
option settings for a group or class of computers, specify either a user or vendor class assignment that overrides
the broader server or scope option defaults.
For special requirements, such as clients with special functions, assign options for specific reserved clients.
Options can also be used to separate and distribute appropriate options for clients with similar or special
configuration needs. For example, DHCP clients on the same floor of a building can be configured with the same
DHCP Class ID value to assign them membership in the same option class. You can then distribute additional or
varied option data to that class during the lease process, overriding any scope or globally provided default options.
Note
 Statically configured values on a client override any DHCP options of any type or level.
Many options are predefined on a DHCP server running Windows Server 2003. Other standard DHCP options can be
added as needed to support any other DHCP client software that recognizes or requires the use of these additional
options. The DHCP Server service running on Windows Server 2003 supports all options defined in RFC 2132,
although most DHCP clients use or support only a small subset of the available RFC-specified options.
The following table contains a list of default DHCP options requested by DHCP clients running Windows Server 2003
and Windows XP. For a complete reference of DHCP options, see “DHCP Tools and Settings.”
Default DHCP Options
Option Code Option Name
1 Subnet mask
3 Router
6 DNS servers
15 DNS domain name
44 WINS/NBNS servers
46 WINS/NetBT node type
47 NetBIOS scope ID
51 Lease time
58 Renewal (T1) time value

59 Rebinding (T2) time value
31 Perform router discovery
33 Static route
43 Vendor-specific information
249 Classless static routes
DHCP Option Parameters

DHCP servers can be configured to provide optional data that fully configures TCP/IP on a client. Some of the most
common DHCP option types configured and distributed by the DHCP server during the lease process include
parameters for the default gateway, DNS, and WINS.
Clients can be configured with:
 Information options. You can explicitly configure these options and any associated values provided to
clients.
 Protocol options. You can implicitly configure these options used by the DHCP Server service based on
server and scope property settings.
You can use the DHCP snap-in to configure these properties and set them for an entire scope or for a single,
reserved client scope.
Information Options
The following table lists the most common types of DHCP information options that can be configured for DHCP
clients. These options can be enabled and configured for each scope that you configure on a DHCP server.
Depending on your network infrastructure, some of these options can be configured as server options, such as DNS
domain name.
Common Information Options
Code Description
3 Router
6 DNS server
15 DNS domain name
Clients can request these DHCP options, and can use the values to set their TCP/IP configurations for the duration
of the lease.
Protocol Options
The following table shows protocol options that DHCP clients can be configured to use when communicating with a
DHCP server to obtain or renew a lease.
Common Protocol Options
Code Description
51 Lease time
53 DHCP message type
55 Special option type used to communicate a parameter request list to the DHCP server
58 Renewal time value (T1)
59 Rebind time value (T2)
The values provided to clients for lease time, T1, and T2 are taken from the scope settings on the DHCP server.
The value provided for DHCP message type is automatically set depending on which packet of the DHCP
conversation is being sent.
Option Classes
Option classes allow quick introduction of custom applications for enterprise networks. DHCP option classes provide
a way to easily configure network clients with the parameters necessary to meet the special requirements of
custom applications. Equipment from multiple vendors on a network can also use different option code numbers for
different functions. The options used to support vendor classes — the vendor class identifier and the vendor-
specific option — are defined in the Internet DHCP options standard reference, RFC 2132.
Windows Server 2003 includes two types of option classes: vendor-defined and user-defined. These classes can be
configured on your servers to offer specialized client support in the following ways:
 Add and configure vendor-defined classes for managing DHCP options assigned to clients identified by
vendor type.
 Add and configure user-defined classes for managing DHCP options assigned to clients that need a similar
DHCP option configuration.
After options classes are defined on a DHCP server, scopes on the server can be configured to assign options for
specific user-defined and vendor-defined option classes.
Vendor Classes
Vendor-defined option classes can be used by DHCP clients to identify the client’s vendor type and configuration
when obtaining a lease from the DHCP server. The client can include the vendor class ID option (option code 60)
when it requests or selects a lease from a DHCP server to identify its vendor class during the lease process.
The vendor class identifier information is a string of character data interpreted by the DHCP servers. Vendors can
choose to define specific vendor class identifiers to convey particular configuration or other identification
information about a client. For example, the identifier might encode the client’s hardware or software configuration.
Most vendor types are derived from standard reserved hardware and operating system-type abbreviation codes
listed in RFC 1700.
When vendor options are specified, the server performs the following additional steps to provide a lease to the
client:
 The server verifies that the vendor class identified by the client request is a recognized class defined on
the server.
If the vendor class is recognized, the server checks to see if any additional DHCP options are configured
for this class in the active scope.
If the vendor class is not recognized, the server ignores the vendor class identified in the client request,
and returns options allocated to the default vendor class (which includes all DHCP Standard options).
 If the scope contains options configured specifically for use with clients in this vendor-defined class, the
server returns those options using the vendor-specific option type (option code 43) as part of its
acknowledgment message.
In most cases, the default vendor class — the DHCP Standard option class — provides a default vendor class for
any Windows DHCP clients or other DHCP clients that do not specify a vendor class ID. In some cases, you might
define additional vendor classes for other DHCP clients, such as printers or some types of UNIX clients. When you
add other vendor classes for these purposes, make sure that the vendor class identifier you use to configure the
class at the server matches the identifier used by clients for your third-party vendor.
User Classes
User classes allow DHCP clients to differentiate themselves by specifying what type of client they are, such as
desktop or server computer. For computers running Windows Server 2003, Windows XP, and Windows 2000, you
can define specific user class identifiers to convey information about a client’s software configuration, its physical
location in a building, or about its user preferences. For example, an identifier can specify that DHCP clients are
members of a user class called “2nd floor, West”, which has need for a specific set of router, DNS, and WINS
server settings. An administrator can then configure the DHCP server to include different option values depending
on the user class of client receiving the lease.
Windows Server 2003 user classes can be used as follows:
 DHCP client computers can include the DHCP user class option when sending DHCP request messages to
the DHCP server. This can specifically identify the client as part of a user class on the server.
 DHCP servers running the Windows 2000 Server or Windows Server 2003 DHCP Server service can
recognize and interpret the DHCP user class option from clients and provide additional options (or a
modified set of DHCP options) based on the client’s user class identity.
For example, shorter leases can be assigned to wireless clients. Or perhaps a particular set of clients might need a
specific set of routes, a specific DNS server, or a specific default gateway.
Note
 If user classes are not specified, default settings, such as server options or scope options, are assigned.
A user class can be either a default or custom user class. Microsoft provides three default user classes, as
described in the following table.
Default User Classes Provided by Windows DHCP
Class ID
Class Type String Description
Default User (Unspecified) This class is typically used by most DHCP clients. Clients that are included
Class in this class:
 DHCP clients that cannot be configured with a user class or a

user class ID. This is true for most Windows-based DHCP clients prior
to Windows 2000.
 Clients running Windows Server 2003, Windows XP, or

Windows 2000 configured with a class ID unknown to the DHCP
server.
 Clients that do not otherwise specify a user class ID.
Default RRAS.Microsoft This class is used by the Windows 2000 Server or Windows Server 2003
Routing and DHCP Server service to classify clients making a PPP-type connection
Remote through a remote access server. Typically, this class includes most dial-up
Access class networking clients that use DHCP to obtain a lease, including remote access
clients that cannot be configured with a Routing and Remote Access user
class or a Routing and Remote Access user class ID.
See “DHCP and Routing and Remote Access” later in this topic for details
about the interaction between a Routing and Remote Access server and a
DHCP server and how DHCP servers identify remote access clients.
Default BOOTP This class is used by the Windows 2000 Server or Windows Server 2003
BOOTP class DHCP Server service to classify any clients recognized as BOOTP clients.
Use the Microsoft default user classes to isolate specific configuration details for clients with special needs, such as
older clients or clients that use BOOTP or Routing and Remote Access. For example, you might want to include and
assign special BOOTP option types (such as option codes 66 and 67) for clients that are BOOTP type, or shorten the
lease time for remote access clients.
You can also add and configure custom user classes for use by DHCP clients running Windows 2000, Windows XP,
and Windows Server 2003. For a custom user class to work properly, the client must use the same custom
identifier when requesting options as was used when the class was defined on the DHCP server
The user class option field permits only one ASCII text string to be used for identifying clients. This means each
client computer can be identified only as a member of a single user class by the DHCP server. You can use
additional user classes to make new hybrids from your other user classes to accommodate clients that need
configuration for multiple user classes. For example, if you have two user classes, one called “mobile” with short
lease times assigned and another called “engineer” with an option assigned to configure a high-performance server
for its clients, you can make a new hybrid user class called “mobile-engineer” that contains both special option
value settings.
MADCAP and Multicast DHCP

Multicast Address Dynamic Client Allocation Protocol (MADCAP) is modeled after the DHCP standard. MADCAP
assists in simplifying and automating configuration of multicast groups on your network, but it is not required for
the operation of multicast groups or for the DHCP Server service. Multicast scopes provide only multicast address
configuration and do not support or use other DHCP-assignable options.
Multicast scopes configured on the DHCP server define ranges of IP multicast addresses. Similar to allocating
unicast IP addresses, IP multicast addresses are allocated to MADCAP clients. A MADCAP address is configured
separately from a primary IP address. Computers that use either static or dynamic IP configuration through a DHCP
server can be MADCAP clients.
In Windows Server 2003, the DHCP Server service supports both DHCP and MADCAP, although these services
function separately. Clients of one do not depend on the use or configuration of the other.
Clients that do not support the MADCAP service or are unable to contact and obtain multicast configuration from a
MADCAP server can be configured in other ways so that they participate in either permanent or temporary
multicast groups on the network.
In all TCP/IP networks, each computer requires a unique primary unicast IP address for each network interface.
You must assign this required primary unicast IP address before you can configure a computer to support and use
secondary IP addresses such as multicast IP addresses.
DHCP Protocols
In Windows Server 2003, the DHCP Server service includes support for the Dynamic Host Configuration Protocol
(DHCP), the Multicast Address Dynamic Client Allocation Protocol (MADCAP), and the Bootstrap Protocol (BOOTP).
DHCP
DHCP servers communicate with DHCP clients by using a series of DHCP messages. The format of DHCP messages
is based on the message format used with the BOOTP protocol.
RFC 2131 defines the format for each message sent between a DHCP client and a DHCP server. The following table
shows the possible fields in the DHCP messages.
DHCP Message Fields
Field
Field Friendly Length
Name Name (Octets) Description
op Message 1 Message type

Type
htype Hardware 1 Hardware address type. Defined at

Address Type http://www.iana.org/assignments/arp-parameters
hlen Hardware 1 Hardware address length in octets

Address
Length
hops Hops 1 Value is set to zero by DHCP clients. Optionally used to count the
number of relay agents that forwarded the message.
xid Transaction 4 A random number used to associate messages and responses between
ID a client and a server.
secs Seconds 2 Seconds elapsed since client began address acquisition or renewal
process.
flags Flags 2 Flags set by client. The Broadcast flag is set if the client cannot
receive unicast IP datagrams (for example, before it is configured with
an IP address).
ciaddr Client IP 4 This field is only filled in if the client has an IP address and can
Address respond to ARP requests.
yiaddr Your IP 4 Address given to the DHCP client by the DHCP server
Address
siaddr DHCP Server 4 IP address of the server that is offering a lease

IP Address
giaddr Gateway IP 4 DHCP relay agent IP address

Address
chaddr Client 16 Client hardware address

Hardware
Address
sname Server Host 64 Optional server host name. Not used in Windows Server 2003
Name
file Boot File 128 The name of the file containing the boot image for a BOOTP client
Name
options Options variable Optional parameters field. In the DHCP protocol packet, each option
begins with a single octet tag, which holds the option code, and a
second octet, which describes the option data length, in bytes. For a
complete list of the DHCP options available by default on a DHCP
server running on Windows Server 2003, see “DHCP Tools and
Settings.”
For a complete view of how these fields are used in each DHCP message, see RFC 2131 or use a network
monitoring tool, such as Netmon, to view the DHCP messages.
MADCAP
Windows Server 2003 includes a Multicast Address Dynamic Client Allocation Protocol (MADCAP) Server service to
support dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks.
Whereas DHCP unicast scopes provide client configurations by allocating ranges of IP addresses for point-to-point
communication between two networked computers, multicast scopes provide ranges for multicast IP addresses.
These addresses are reserved for multicast operation using directed transmission from one point to multiple points.
A multicast address is shared by many computers. A group of TCP/IP computers can use a single multicast IP
address to send directed communication to all computers with which they share the use of the group address. An
IP datagram that is sent to the multicast address is forwarded to all members of that multicast group.
Dynamic Membership
Multicast addresses support dynamic membership, allowing individual computers to join or leave the multicast
group at any time. The size of the group is not limited, and computers can be members of multiple groups. In
addition, any computer that uses TCP/IP can send datagrams to any multicast group.
Multicast Address Ranges

You can permanently reserve multicast group addresses or temporarily assign and use them. A permanent group is
made by permanently reserving a multicast IP address (224.0.0.0 to 239.255.255.255) with the Internet Assigned
Numbers Authority (IANA). The reserved address then becomes a well-known address, indicating a specific
multicast group that exists regardless of whether group member computers are present on the network. Any
multicast IP address that is not permanently reserved with the IANA can then be used dynamically to assign and
form temporary multicast groups. These temporary groups can exist as long as one or more computers on the
network are configured with the group’s address and actively share in its use.
BOOTP
Bootstrap Protocol (BOOTP) is a computer configuration protocol developed before DHCP. DHCP improves on
BOOTP and resolves specific limitations that BOOTP had as a computer configuration service. RFC 951 defines
BOOTP.
Whereas BOOTP configures diskless workstations with limited boot capabilities, DHCP configures networked
computers, that have local hard drives and full boot capabilities.
Likewise, although both BOOTP and DHCP allocate IP addresses to clients during startup, they use different
methods of allocation. BOOTP typically provides fixed allocation of a single IP address for each client, permanently
reserving this address in the BOOTP server database. DHCP typically provides dynamic, leased allocation of
available IP addresses, reserving each DHCP client address temporarily in the DHCP database.
Because of the relationship between BOOTP and DHCP, both protocols share some defining characteristics. BOOTP
and DHCP use nearly identical request messages and reply messages. Both protocols enclose each protocol
message in a single User Datagram Protocol (UDP) datagram of 576 bytes. Message headers are the same for both
BOOTP and DHCP, except for the final message header field that carries optional data. For BOOTP, this optional
field is called the vendor-specific area and is limited to 64 bytes. For DHCP, this optional field is called the
options field and is at least 312 bytes long.
Both BOOTP and DHCP use the same reserved protocol ports for sending and receiving messages between servers
and clients. Both BOOTP and DHCP servers use UDP port 67 to listen for and receive client request messages.
BOOTP and DHCP clients typically reserve UDP port 68 for accepting message replies from either a BOOTP server
or DHCP server.
Because DHCP and BOOTP messages use nearly identical format types and packet structures, and use the same
well-known service ports, BOOTP or DHCP relay agent programs usually treat BOOTP and DHCP messages as the
same message type and do not differentiate between them.
BOOTP clients do not rebind or renew configuration with the BOOTP server except when the system restarts,
whereas DHCP clients do not require a system restart to rebind or renew configuration with the DHCP server.
Instead, clients automatically enter the rebinding state at defined intervals to renew their leased address allocation
with the DHCP server. This process occurs in the background and is transparent to the user.
BOOTP uses a two-phase bootstrap configuration process in which clients contact BOOTP servers to perform
address determination and boot file name selection, and clients also contact Trivial File Transfer Protocol (TFTP)
servers to perform file transfer of their boot image. DHCP uses a single-phase boot configuration process whereby
a DHCP client negotiates with a DHCP server to determine its IP address and obtain any other initial configuration
details it needs for network operation.
Because BOOTP clients contact TFTP servers to perform file transfer of their boot image and Windows Server 2003
does not provide a TFTP file service, you need a third-party TFTP server to support BOOTP clients that must boot
from an image file (usually diskless workstations). You also need to configure your DHCP server to provide
supported BOOTP/DHCP options.
DHCP Options Supported for BOOTP Clients

To obtain other options, BOOTP clients must specify DHCP option code 55 (the Options Request List parameter) in
the BOOTP request. BOOTP clients that do not specify option 55 can still retrieve the options listed in the following
table from DHCP servers running Windows NT Server 4.0 or later, if they are configured on the server.
DHCP Options for BOOTP Clients

Code Option Name
1 Subnet Mask
3 Router
4 Time Server
5 Name Server
9 LPR Server
12 Computer Name
15 Domain Name
17 Root Path
42 NTP Servers
44 WINS Server
45 NetBIOS over TCP/IP Datagram Distribution Server
46 NetBIOS over TCP/IP Node Type
47 NetBIOS over TCP/IP Scope
48 X Window System Font Server
49 X Window System Display Manager
69 SMTP Server
70 POP3 Server
DHCP servers running Windows Server 2003 return the options in the order listed above and return as many
options as can fit in a single datagram response. For more information about individual DHCP options, see “DHCP
Tools and Settings.”
Note
 When configuring client reservations for use with BOOTP clients, remember that DHCP options can apply
equally to DHCP and BOOTP clients.
BOOTP Table
Each record in the BOOTP table has three fields of information that is returned to the BOOTP client:
 Boot Image. Identifies the generic file name (such as “unix”) of the requested boot file, based on the
BOOTP client’s hardware type.
 File Name. Identifies the full path of the boot file (such as “/etc/vmunix”) that the BOOTP server returns
to the client by using TFTP.
 File Server. Identifies the name of the TFTP server used to store the boot file.
To add entries in the BOOTP table, use the DHCP snap-in.
DHCP Processes and Interactions

In Windows Server 2003, the DHCP Server service interacts with several other services, including the Active
Directory directory service, DNS, and the Routing and Remote Access service.
Detecting Unauthorized DHCP Servers

An unauthorized DHCP server on a network can cause a variety of problems, such as the leasing of incorrect IP
addresses and options. To protect against this type of problem, when a DHCP server running Windows 2000 or
Windows Server 2003 starts on the network, it first attempts to determine if it is authorized to service clients.
There are different methods used depending on how the network is configured.
Unauthorized Domain Member DHCP Servers

A domain member DHCP server queries Active Directory. The DHCP server compares its IP address and server
name to the list of authorized DHCP servers. If either the server name or IP address is found on the list of
authorized DHCP servers, the server is authorized as a DHCP server. If no match is found, the server is not
authorized in Active Directory, the server does not respond to DHCP traffic, and a system event is logged.
Note
 This process of authorizing DHCP servers is useful for only DHCP servers running Windows 2000 or
Windows Server 2003. This process cannot be used for DHCP servers running Windows NT Server 4.0, or
servers running non-Windows-based DHCP Server services. Only a member of the Enterprise Admins
group can authorize or unauthorize a DHCP server in Active Directory.
Unauthorized Workgroup DHCP Servers

A Windows Server 2003 workgroup member DHCP server uses the following process to detect other DHCP servers
currently running on the reachable network and to determine if it is authorized to provide service.
1. When the DHCP Server service starts, it sends a DHCPInform request message to the reachable network,
using the local limited broadcast address (255.255.255.255), to locate other DHCP servers on the
network.
This message includes several vendor-specific option types that are known and supported by other DHCP
servers running Windows Server 2003. These other DHCP servers will respond with a DHCPAck containing
information indicating if they are authorized domain member or workgroup member servers.
2. When queried, other DHCP servers running Windows 2000 and Windows Server 2003 reply with DHCPAck
messages to acknowledge and answer with workgroup or domain membership information.
3. If an Active Directory domain member DHCP server is found, then the workgroup member server
determines that it is not authorized and does not service clients. If other workgroup servers are found, the
workgroup member server determines that it is authorized to service clients, and begins service. It then
performs the check again at one-hour intervals.
DHCP and DNS

Domain Name System (DNS) servers provide name resolution for network clients. DNS resolves a fully qualified
domain name (FQDN) to its corresponding IP address.
Although DHCP provides a powerful mechanism for automatically configuring client IP addresses, prior to
Windows 2000, the DHCP Server service did not notify DNS to update the DNS records on behalf of the client.
Specifically, DHCP did not map the client name to an IP address and did not update IP address-to-name mappings
using DNS dynamic update.
Without a way for DHCP to interact with DNS, the information maintained by DNS for a DHCP client might be
incorrect. For example, a client can acquire its IP address from a DHCP server, but the DNS records might not
reflect the IP address acquired nor provide a mapping from the new IP address to the FQDN.
DNS Dynamic Updates

In Windows 2000 and Windows Server 2003, DHCP servers and clients can register record updates if the DNS
server supports DNS dynamic updates. In Windows 2000 Server and Windows Server 2003, the DNS service
supports DNS dynamic updates.
A DHCP server running Windows Server 2003 can register with a DNS server and update pointer (PTR) and address
(A) resource records on behalf of its DHCP-enabled clients by using the DNS dynamic update protocol.
The ability to register A and PTR resource records lets a DHCP server act as a DNS registration proxy for clients
using Windows NT 4.0, Windows 98, or Windows Millennium Edition, and possibly other clients that are not able to
register the updates on their own, as shown in the following figure.
DHCP Server Performing DNS Dynamic Update on Behalf of DHCP Client
DHCP clients running Windows 2000, Windows XP, and Windows Server 2003 interact with DNS differently than
DHCP clients running earlier versions of Windows. DHCP clients running Windows XP, Windows 2000, or Windows
Server 2003 typically update their own dynamic forward lookup names, as shown in the following figure.
DHCP Client and DHCP Server Performing DNS Dynamic Update

An additional DHCP option code (option code 81) enables the return of a client’s FQDN to the DHCP server. If
implemented, the DHCP server can dynamically update an individual computer’s resource records on a DNS server
by using the DNS dynamic update protocol.
For more information about DNS dynamic updates, see “DNS Technical Reference.”
Secure DNS Dynamic Updates

By itself, DNS dynamic update is not secure; any client can modify DNS records. When secure DNS dynamic update
is configured, the authoritative name server accepts updates only from clients and servers that are authorized to
make DNS dynamic updates to the appropriate objects in Active Directory. Secure DNS dynamic update is available
only on Active Directory–integrated zones.
Secure DNS dynamic update protects zones and resource records from being modified by unauthorized users by
allowing you to specify the users and groups that can modify zones and resource records. By default, Windows
Server 2003, Windows XP Professional, and Windows 2000 clients attempt unsecured DNS dynamic updates first. If
that request fails, they attempt secure updates.
When using multiple DHCP servers and secure DNS dynamic updates, add each of the DHCP servers as members of
the DnsUpdateProxy global security group so that any DHCP server can perform a secure DNS dynamic update for
any record. Otherwise, when a DHCP server performs a secure DNS dynamic update for a record, that DHCP server
is the only computer that can update the record.
DHCP and Routing and Remote Access

The Windows Server 2003 DHCP Server service interacts with the Windows Server 2003 Routing and Remote
Access Server service in two specific ways. When Routing and Remote Access is used to provide remote access to
PPP clients, the remote access server obtains IP addresses from the DHCP server, which it then assigns to the PPP
clients.
DHCP also interacts with routers when DHCP clients and DHCP servers are on different subnets from each other. In
this situation, a router that can act as a DHCP relay agent must be present on the subnet of the DHCP client. You
can use the Windows Server 2003 Routing and Remote Access service to act as a DHCP relay agent.
Configuration of PPP Clients

When the Routing and Remote Access service is configured to use DHCP to obtain IP addresses for TCP/IP based
clients, the Routing and Remote Access service instructs the DHCP Client service to obtain 10 IP addresses from a
DHCP server when the first PPP client connects. The Routing and Remote Access service uses the first IP address
obtained from DHCP for the Internal interface, which is a logical interface that represents the connections to all
PPP-based clients. Subsequent addresses are assigned to TCP/IP-based PPP clients as they connect. After the PPP
client disconnects, the now-unassigned IP address is reused for a future PPP connection.
The remote access server uses the IP addresses from these leases to configure PPP clients, but discards all options
contained in the leases.
When all 10 IP addresses are used, the Routing and Remote Access service obtains another block of 10 IP
addresses from the DHCP server.
With a Windows NT 4.0–based remote access server, DHCP-allocated addresses are recorded and reused when the
remote access service is restarted. In Windows Server 2003 and Windows 2000 Server, the Routing and Remote
Access service releases all DHCP-allocated IP addresses by using DHCPRelease messages each time the service is
stopped.
If the DHCP server becomes unavailable, the DHCP Client service on the Routing and Remote Access server assigns
APIPA addresses to TCP/IP-based PPP clients. APIPA addresses for remote access connectivity work only if the
network to which the remote access client is attached is also using APIPA addresses (which is not a recommended
configuration). If the local network is not using APIPA addresses, remote access clients can only obtain point-to-
point remote access connectivity.
The Routing and Remote Access service uses a specific LAN interface to obtain DHCP-allocated IP addresses for
remote access clients. You can select which LAN interface to use on the IP tab of the Properties dialog box of a
server in the Routing and Remote Access snap-in. If the Routing and Remote Access server has more than one
LAN interface installed, the Routing and Remote Access Server Setup Wizard prompts you to select the LAN
interface.
Options for PPP Clients

Although the remote access server running Windows Server 2003 discards all options from the leases it obtains
from the DHCP server, PPP clients do receive specific configuration information, such as WINS server and DNS
server assignments, from the settings of the remote access server as part of the negotiation of the PPP connection.
However, clients running Windows 2000, Windows XP, or Windows Server 2003 can receive additional configuration
information from the DHCP server, by using a DHCPInform message after the connection has been established.
These options are available only if the VPN server has the DHCP Relay Agent routing protocol component
configured with the IP address of the DHCP server.
The following three figures show the three steps of the remote access server obtaining leases from the DHCP
server.
First, when the first PPP client connects to the remote access server, the remote access server obtains 10 IP
addresses from the DHCP server as shown in the following figure.
Remote Access Server Obtains IP Addresses
Next, the remote access server uses Internet Protocol Control Protocol (IPCP) to configure the IP address of the
client, as well as assign the DNS server and WINS server settings that are configured on the selected interface of
the remote access server, as shown in the following figure.
Remote Access Server Configures PPP Client

After the remote access client has an IP address, it sends a unicast DHCPInform message to request options from
the DHCP server to the remote access server. The remote access server must also be configured with the DHCP
Relay Agent routing protocol component. The remote access server, acting in its role as a DHCP relay agent, then
sends the DHCPInform message to the DHCP server. The DHCP server responds with the options in a DHCPAck
message, which is sent back to the remote access server. Finally, the DHCP relay agent on the remote access
server sends the DHCPAck message to the remote access client, as shown in the following figure.
PPP Client Obtains DHCP Options
The following table lists the DHCP options that are requested by the client in the DHCPInform message.
DHCP Options Requested in DHCPInform Message
Code Description
1 Subnet mask
6 DNS servers
15 DNS domain name
43 Vendor-specific information
249 Classless static routes
DHCP Relay Agents

A DHCP relay agent is a hardware device or software program that can pass DHCP or BOOTP messages between
DHCP clients and servers, according to the RFC 2131 specification for DHCP. DHCP relay agents act as proxies,
forwarding messages from a subnet to one or more DHCP servers. Some DHCP messages are sent as broadcasts,
so without relay agents and the ability to pass DHCP and BOOTP messages across routers, every subnet on a
network must have its own DHCP server.
Most routers support acting as a DHCP relay agent. Alternatively, if a router cannot function as a DHCP relay agent,
a computer that can function as a DHCP relay agent must be configured on each subnet to which the router is
connected.
In cases where it is impractical or impossible to configure routers to act as a DHCP relay agent, you can configure a
computer running Windows Server 2003 or Windows 2000 Server, to act as a relay agent by enabling the Routing
and Remote Access service and installing the DHCP Relay Agent routing protocol component.
How Relay Agents Work

The following figure shows how Client C on Subnet 2 obtains a DHCP address lease from DHCP Server 1 on Subnet
1.
Using a Relay Agent
1. DHCP Client C broadcasts a DHCPDiscover message on Subnet 2 as a UDP datagram over well-known UDP
port 67, which is the port reserved and shared for BOOTP and DHCP server communication.
2. The relay agent, in this case a DHCP relay-enabled router, examines the Gateway IP Address field (also
known as the giaddr field) in the DHCP message header. If the field has an IP address of 0.0.0.0, the
agent fills the Gateway IP Address field with the IP address assigned to the interface on which the
DHCPDiscover was received, and forwards the DHCPDiscover message as a unicast message to the DHCP
server on Subnet 1.
3. When DHCP Server 1 receives the DHCPDiscover message, it examines the Gateway IP Address field to
determine if the packet was relayed. The DHCP server then determines whether it can supply an IP
address lease to clients on the subnet indicated by the address in the Gateway IP Address field.
For example, if the Gateway IP Address field has an IP address of 192.168.45.2, the DHCP server checks
its DHCP scopes for a scope range that includes 192.168.45.2 (the gateway IP address in the packet). To
find a match, the DHCP server determines whether the IP address 192.168.45.2 matches the network ID
of each scope. It determines the network ID of each scope by ANDing any IP address in the scope with its
corresponding subnet mask. In this case, the DHCP server checks to see which scope includes addresses
for Subnet 2. If a scope exists that matches this criterion, the DHCP server selects an available address
from the matched scope to use in an IP address lease offer response to the client.
4. DHCP Server 1 sends a DHCPOffer message directly to the relay agent identified in the Gateway IP
Address field.
5. The relay agent relays the DHCPOffer message to the DHCP client.
Depending on the value of the Broadcast flag in the DHCPOffer message (which was copied from the
DHCPDiscover message), the DHCP relay agent either unicasts or broadcasts the DHCPOffer message.
6. By using a similar process, a DHCPRequest message is relayed from client to server, and a DHCPAck
message is relayed from server to client.

What Is DHCP?

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

What Is DHCP?

Transféré par

Droits d'auteur :

Formats disponibles

What Is DHCP?

Updated: March 28, 2003

 It is necessary to have an understanding of basic TCP/IP concepts, including a working knowledge of

 Centralized and automated TCP/IP configuration.

 The ability to define TCP/IP configurations from a central location.

Why use DHCP

 Valid TCP/IP configuration parameters for all clients on the network.

A DHCP-enabled client, upon accepting a lease offer, receives:

 A valid IP address for the subnet to which it is connecting.

Terms and Definitions

DHCP Terms and Definitions

DHCP Tools and Settings

DHCP Tools and Settings

 Create and manage scopes, including superscopes and multicast scopes.

 Review active leases for each scope.

Structure of Pad Option

Structure of End Option

Structure of Subnet Mask

Code Length Subnet Mask

1 4 subnet mask in binary format

Structure of Time Offset

Code Length Time Offset

Code Length Address 1 Address N

3 n IP address in binary format IP address in binary format

Structure of Time Server

Code Length Address 1 Address N

4 n IP address in binary format IP address in binary format

IEN Name Server

Structure of IEN Name Server

Code Length Address 1 Address N

5 n IP address in binary format IP address in binary format

Structure of DNS Servers

Code Length Address 1 Address N

6 n IP address in binary format IP address in binary format

Structure of Log Server

Code Length Address 1 Address N

7 n IP address in binary format IP address in binary format

Code Length Address 1 Address N

8 n IP address in binary format IP address in binary format

Structure of LPR Server

Code Length Address 1 Address N

9 n IP address in binary format IP address in binary format

Structure of Impress Server

Code Length Address 1 Address N

10 n IP address in binary format IP address in binary format

Resource Location Server

Structure of Resource Location Server

Code Length Address 1 Address N

11 n IP address in binary format IP address in binary format

Structure of Host Name

Code Length Host Name

Boot File Size

Structure of Boot File Size

Code Length File Size

Merit Dump File

Structure of Merit Dump File

Code Length Dump File Path

DNS Domain Name

Structure of DNS Domain Name

Code Length Domain Name

Structure of Swap Server

Code Length Swap Server Address

16 4 IP address in binary format