Understanding DHCP Ports

Dynamic Host Configuration Protocol (DHCP) is used to assign hosts IP addressing information dynamically, which includes IP address, subnet mask, default gateway, and additional optional parameters, such as Domain Name Service (DNS) servers, Windows Internet Name Service (WINS) servers, and Network Time Protocol (NTP) server information. DHCP ports are UDP port 68 and 69. Cisco IOS routers and some switches can be configured as both DHCP clients and DHCP servers.

We cover DHCP in great detail in our Network+, Cisco CCNA, Wireshark WCNA and other courses.

Client States and Message Exchanges

DHCP is a client/server protocol wherein the server provides the client dynamic addressing information. The server can be a standalone server or a Cisco IOS router or switch that can provide DHCP server functionality. While clients are typically network hosts, such as workstations, Cisco IOS routers and switches can also be configured as DHCP clients, allowing them to receive addressing information dynamically from the DHCP server.

DHCP clients transition through a series of states upon initialization. During these phases, the clients and servers exchange different messages. Clients transition through the following states:

• Initializing
• Selecting
• Requesting
• Bound
• Renewing
• Rebinding

When a client first boots up, it is in the Initializing state. In this state, the client sends out the DHCPDISCOVER message UDP port 67 (BOOTP server) to the Broadcast address FFFF:FFFF:FFFF (Layer 2)/255.255.255.255 (Layer 3). Because at this point the client has no IP address, the source IP address of this Broadcast will be 0.0.0.0.

If a DHCP server exists on the local subnet and is configured and operating correctly, the DHCP server will hear the Broadcast and respond with a DHCPOFFER message using UDP port 68 (BOOTP client). However, if no DHCP server resides on the local subnet, then a DHCP or BOOTP Relay is required to forward the DHCPDISCOVER message to a remote DHCP server. If this functionality is not enabled, the client will not be able to communicate with the server.

After the client receives the DHCPOFFER message from the DHCP server, the client then transitions into the selecting state. In the event that multiple DHCP servers have responded with DHCPOFFER messages, the client effectively selects which DHCPOFFER to accept during this state. Most commonly, the client will accept the message from the first server to respond.

This DHCPOFFER message contains the initial configuration information for the DHCP client. This information includes parameters such as the IP address, subnet mask, default gateway, and other additional parameters, such as lease duration, renewal time, domain name, DNS server, and WINS server information, for example. The server will send the DHCPOFFER to the Broadcast address but will include the hardware address of the client in 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 or BOOTP Relay Agent from which the DHCPDISCOVER came. The DHCP or 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 client.

After receiving the DHCPOFFER, the client moves into the Requesting state. In this state, the client responds to the selected DHCP server (typically the first one it heard from) with a DHCPREQUEST message, which indicates that it is willing to accept the parameters in the DHCPOFFER message. The client does not respond to the other DHCPOFFER messages; instead, the DHCP client simply ignores them, implicitly declining the information received from those servers.

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 because it has not yet received verification that it is clear to use the address.

When the DHCP server receives the DHCPREQUEST from the client, it acknowledges it by sending the client a DHCPACK. When the client receives this message from the server, it transitions to the Bound state. The DHCPACK message has a source IP address of the DHCP server, and the destination address is a Broadcast. This message contains all the parameters that the client requested in the DHCPREQUEST message. 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 DHCPACK tells the client that it is free to use the provided address to access the network. After this message has been sent, the DHCP server then stores the lease in the database and uniquely identifies it using the client identifier and the associated IP address. Both the client and the 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. The sequence of messages exchanged between server and client during this phase is illustrated in Figure 1 below:

Fig. 1. DHCP Client and Server Message Exchanges

After getting a lease from the DHCP server, the client must renew that lease when one-half of the lease time has expired. To do so, the client transitions to the renewing state and sends a DHCPREQUEST message to the server that holds the current lease. Upon receiving this message, the server responds to the client with a DHCPACK message that contains the new lease and any other new configuration parameters that may have been made since the previous lease. For example, this might include an updated DNS server IP address.

If the client is unable to reach the server holding the lease, it will attempt to renew the address from any DHCP server if the original DHCP server has not responded to the renewal requests within a specified interval.

A client transitions into the Rebinding state if, after it has been allocated addressing information, it is restarted. In this state, the client will specifically request the previously leased IP address using a DHCPREQUEST packet, which will still have the source IP address 0.0.0.0 and the destination Broadcast address 255.255.255.255. If the DHCP server determines that the client can still use the requested IP address, it will either remain silent or send a DHCPACK for the DHCPREQUEST. If the server determines that the client cannot use the requested IP address, it will send a DHCPNACK back to the client. The client will then move to the Initializing state and send a DHCPDISCOVER message. The entire process starts again.

Read the DHCP RFC.

We teach DHCP in multiple courses on this website.