DHCP message type

Reference 0x01 Message DHCPDISCOVER Use The client is looking for available DHCP servers. The server response to the client DHCPDISCOVER. The client broadcasts to the server, requesting offered 0x03 DHCPREQUEST parameters from one server specifically, as defined in the packet. The client-to-server 0x04 DHCPDECLINE communication, indicating that the network address is already in use. The server-to-client communication with 0x05 DHCPACK configuration parameters, including committed network address. The server-to-client 0x06 DHCPNAK communication, refusing the request for configuration parameter. The client-to-server 0x07 DHCPRELEASE communication, relinquishing network address and canceling remaining lease. The client-to-server communication, asking for 0x08 DHCPINFORM only local configuration parameters that the client already has externally configured as an address. 0x02 DHCPOFFER DHCPDISCOVER

When a client boots up for the first time, it is said to be in the Initializing state, and transmits a DHCPDISCOVER message on its local physical subnet over User Datagram Protocol (UDP) port 67 (BootP server). Since the client has no way of knowing the subnet to which it belongs, the

DHCPDISCOVER is an all subnets broadcast (destination IP address of 255.255.255.255), with a source IP address of 0.0.0.0. The source IP address is 0.0.0.0, since the client does not have a configured IP address. If a DHCP server exists on this local subnet and is configured and operating correctly, the DHCP server will hear the broadcast and respond with a DHCPOFFER message. If a DHCP server does not exist on the local subnet, there must be a DHCP/BootP Relay Agent on this local subnet to forward the DHCPDISCOVER message to a subnet that contains a DHCP server.

This relay agent can either be a dedicated host (for example, Microsoft Windows Server), or router (for example, a Cisco router configured with interface level IP helper statements).

DHCPOFFER

A DHCP server that receives a DHCPDISCOVER message may respond with a DHCPOFFER message on UDP port 68 (BootP client). The client receives the DHCPOFFER and moves into the Selecting state. This DHCPOFFER message contains initial configuration information for the client. For example, the DHCP server will fill in the yiaddr field of the DHCPOFFER message with the requested IP address. The subnet mask and default gateway are specified in the options field, subnet mask and router options, respectively. Other common options in the DHCPOFFER message include IP Address lease time, renewal time, domain name server, and NetBIOS name server (WINS). The DHCP server will send the DHCPOFFER to the broadcast address, but will include the clients hardware address in the chaddr field of the offer, so the client knows that it is the intended destination. In the event that the DHCP server is not on the local subnet, the DHCP server will send the DHCPOFFER, as a unicast packet, on UDP port 67, back to the DHCP/BootP Relay Agent from which the DHCPDISCOVER came. The DHCP/BootP Relay Agent will then either broadcast or unicast the DHCPOFFER on the local subnet on UDP port 68, depending on the Broadcast flag set by the Bootp client.

DHCPREQUEST

After the client receives a DHCPOFFER, it responds with a DHCPREQUEST message, indicating its intent to accept the parameters in the DHCPOFFER, and moves into the Requesting state. The client may receive multiple DHCPOFFER messages, one from each DHCP server that received the original DHCPDISCOVER message. The client chooses one DHCPOFFER and responds to that DHCP server only, implicitly declining all other DHCPOFFER messages. The client identifies the selected server by populating the Server Identifier option field with the DHCP server's IP address. The DHCPREQUEST is also a broadcast, so all DHCP servers that sent a DHCPOFFER will see the DHCPREQUEST, and each will know whether its DHCPOFFER was accepted or declined. Any additional configuration options that the client requires will be included in the options field of the DHCPREQUEST message. Even though the client has been offered an IP address, it will send the DHCPREQUEST message with a source IP address of 0.0.0.0. At this time, the client has not yet received verification that it is clear to use the IP address.

DHCPACK

After the DHCP server receives the DHCPREQUEST, it acknowledges the request with a DHCPACK message, thus completing the initialization process. The DHCPACK message has a source IP address of

the DHCP server, and the destination address is once again a broadcast and contains all the parameters that the client requested in the DHCPREQUEST message. When the client receives the DHCPACK, it enters into the Bound state, and is now free to use the IP address to communicate on the network. Meanwhile, the DHCP server stores the lease in its database and uniquely identifies it using the client identifier or chaddr, and the associated IP address. Both the client and server will use this combination of identifiers to refer to the lease. The client identifier is the Mac address of the device plus the media type. Before the DHCP client begins using the new address, the DHCP client must calculate the time parameters associated with a leased address, which are Lease Time (LT), Renewal Time (T1), and Rebind Time (T2). The typical default LT is 72 hours. You can use shorter lease times to conserve addresses, if needed.

DHCPNAK

If the selected server is unable to satisfy the DHCPREQUEST message, the DHCP server will respond with a DHCPNAK message. When the client receives a DHCPNAK message, or does not receive a response to a DHCPREQUEST message, the client restarts the configuration process by going into the Requesting state. The client will retransmit the DHCPREQUEST at least four times within 60 seconds before restarting the Initializing state.

DHCPDECLINE

The client receives the DHCPACK and will optionally perform a final check on the parameters. The client performs this procedure by sending Address Resolution Protocol (ARP) requests for the IP address provided in the DHCPACK. If the client detects that the address is already in use by receiving a reply to the ARP request, the client will send a DHCPDECLINE message to the server and restart the configuration process by going into the Requesting state.

DHCPINFORM

If a client has obtained a network address through some other means or has a manually configured IP address, a client workstation may use a DHCPINFORM request message to obtain other local

configuration parameters, such as the domain name and Domain Name Servers (DNSs). DHCP servers receiving a DHCPINFORM message construct a DHCPACK message with any local configuration parameters appropriate for the client without allocating a new IP address. This DHCPACK will be sent unicast to the client.

DHCPRELEASE

A DHCP client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the DHCP server. The client identifies the lease to be released by the use of the client

identifier field and network address in the DHCPRELEASE message. If you need to extend the

current DHCP pool range, remove the current pool of addresses and specify the new range of IP addresses under the DHCP pool. In order to remove specific IP addresses or a range of addresses that you want to be in the DHCP pool, use the command ipdhcp excluded-address.

Note: If devices use BOOTP, infinite length leases are shown in the DHCP bindings of routers.

Understanding relay agents Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Understanding relay agents

A relay agent is a small program that relays DHCP/BOOTP messages between clients and servers on different subnets. DHCP/BOOTP relay agents are part of the DHCP and BOOTP standards and function according to the Request for Comments (RFCs), standard documents that describe protocol design and related behavior.

DHCP/BOOTP router support

In TCP/IP networking, routers are used to interconnect hardware and software used on different physical network segments called subnets and forward IP packets between each of the subnets. To support and use DHCP service across multiple subnets, routers connecting each subnet should comply with DHCP/BOOTP relay agent capabilities described in RFC 1542.

To be compliant with RFC 1542 and provide relay agent support, each router must be able to recognize BOOTP and DHCP protocol messages and process (relay) them appropriately. Because routers interpret DHCP messages as BOOTP messages (such as a UDP message sent through the same UDP port number and containing shared message structure), a router with BOOTP-relay agent capability typically relays DHCP packets and any BOOTP packets sent on the network.

If a router cannot function as a DHCP/BOOTP relay agent, each subnet must have either its own DHCP server or another computer that can function as a relay agent on that subnet. In cases where it is impractical or impossible to configure routers to support DHCP/BOOTP relay, you can configure a computer running Windows NT Server 4.0 or later to act as a relay agent by installing the DHCP Relay Agent service.

In most cases, routers support DHCP/BOOTP relay. If your routers do not, contact your router manufacturer or supplier to find out if a software or firmware upgrade is available to support this feature.

How relay agents work

A relay agent relays DHCP/BOOTP messages that are broadcast on one of its connected physical interfaces, such as a network adapter, to other remote subnets to which it is connected by other physical interfaces. The following illustration shows how client C on Subnet 2 obtains a DHCP address lease from DHCP server 1 on Subnet 1.

DHCP client C broadcasts a DHCP/BOOTP discover message (DHCPDISCOVER) on Subnet 2, as a User Datagram Protocol (UDP) datagram using the well-known UDP server port of 67 (the port number reserved and shared for BOOTP and DHCP server communication).

The relay agent, in this case a DHCP/BOOTP relay-enabled router, examines the gateway IP address field in the DHCP/BOOTP message header. If the field has an IP address of 0.0.0.0, the agent fills it with the relay agent or router's IP address and forwards the message to the remote Subnet 1 where the DHCP server is located.

When DHCP server 1 on remote Subnet 1 receives the message, it examines the gateway IP address field for a DHCP scope that can be used by the DHCP server to supply an IP address lease.

If DHCP server 1 has multiple DHCP scopes, the address in the gateway IP address field (GIADDR) identifies the DHCP scope from which to offer an IP address lease.

For example, if the gateway IP address (GIADDR) field has an IP address of 10.0.0.2, the DHCP server checks its available set of address scopes for a scope range of addresses that matches the class A IP network that includes the gateway address as a host. In this case, the DHCP server would make a check for a scope of addresses between 10.0.0.1 and 10.0.0.254. If a matching scope exists, the DHCP server selects an available address from the matched scope to use in an IP address lease offer response to the client.

When DHCP server 1 receives the DHCPDISCOVER message, it processes and sends an IP address lease offer (DHCPOFFER) directly to the relay agent identified in the gateway IP address (GIADDR) field.

The router then relays the address lease offer (DHCPOFFER) to the DHCP client.

The client IP address is still unknown, so it has to be broadcast on the local subnet. Similarly, a DHCPREQUEST message is relayed from client to server, and a DHCPACK message is relayed from server to client, according to RFC 1542.

Note

For more information, see Relay agent design issues.