Complete DHCP and DHCP features

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.

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.
Sub-netting	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 sub-manage 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	S
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.requires two things 1.        Ip 2.        Mac address of hop
Exclusion/exclusion range	One or more IP addresses within a DHCP scope that are not allocated by the DHCP 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 server	A DHCP server that has not explicitly been authorized. Sometimes referred to as a 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 Addressing (APIPA)	A TCP/IP feature in Windows XP and Windows Server 2003 that automatically 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.
Super-scope	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.

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.

DHCP Architecture:

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

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

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

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.

Super-scopes

A super-scope allows a DHCP server to provide leases from more than one scope to clients on a single physical subnet. Before you can create a super-scope, you must use the DHCP Microsoft Management Console (MMC) snap-in to define at least one of the scopes to be included in the super-scope. Scopes added to a super-scope are called member scopes. Super-scopes 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 multi-nets. In a situation where multi-nets 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 multi-net located on the other side of BOOTP relay agents.
• Clients need to be migrated to a new scope.

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

DHCP Discover

Broadcast by a DHCP client when it first attempts to connect to the network. The DHCP Discover message requests IP address information from a DHCP server.

DHCPOFFER

Broadcast by each DHCP server that receives the client DHCP Discover message and has an IP address configuration to offer to the client. The DHCP Offer message contains an un-leased 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 DHCP Offer message. The client accepts the best offer, which for a Windows DHCP client is the first DHCP Offer 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.

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

o    If the client is using the Automatic Private IP Addressing (APIPA) alternate configuration, the client self-configures an IP address for its interface.

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

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

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.

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 datagram’s 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.

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.

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

 

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.

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