Dynamic Host Configuration Protocol (DHCP) is a network protocol used to dynamically assign IP addresses and other network parameters to devices on a network.
When a device joins a network, it sends a broadcast message requesting an IP address. A DHCP server on the network captures this message and responds by providing an available IP address and other necessary network configuration parameters, such as subnet mask and default gateway.
DORA (Discover, Offer, Request, Acknowledge) is the four-step process used by DHCP for communication between DHCP servers and clients. The communication is carried out using the UDP transport protocol and ports 67 and 68.
In the Discovery stage: The DHCP client searches for a DHCP server. The DHCP client broadcasts a DHCPDISCOVER message and only DHCP servers respond to the message.
The Offer stage consists for a DHCP Server to offer an unassigned IP address (selected from a pre-defined pool) to the DHCP client, along with other config parameters for a given amount of time (lease time).
During the Request stage, the DHCP client selects an IP address in the case for example of multiple DHCP servers answering to its discover message and broadcasts to each DHCP server a DHCPREQUEST message containing the selected IP address.
The Ack phase is when the DHCP server acks the IP address selected by the client.
When an IP address is automatically assigned, there is also a time limit for that assignment, the lease time, which applies to other network configuration parameters as well.
To continue using the same IP address and network parameters, the device must request a new DHCP lease before the lease time expires. If the lease is not renewed, the IP address may be assigned to another device on the network.
When the IP address lease reaches 50% (T1), the DHCP client automatically sends a DHCP Request message to the DHCP server to renew the IP address lease. If a DHCP ACK message is received, the IP address lease is successfully renewed. If a DHCP NAK message is received, the DHCP client re-initiates the renewal procedure.
When the IP address lease reaches 87.5% (T2), if the DHCP client has not received a DHCP ACK message yet, it broadcasts a DHCP Request message to renew its IP address lease. If a DHCP ACK message is received, the IP address lease is successfully renewed. If a DHCP NAK message is received, the DHCP client re-initiates the renewal procedure.
If the DHCP client receives no response before the IP address lease expires, the DHCP client stops using the current IP address and sends a DHCP Discover message to request a new IP address.
In larger enterprises where there are multiple subnets or VLANs, having a DHCP server per subnet would become difficult to manage. DHCP Relay is used when the DHCP server and the DHCP client are not on the same subnet.
A DHCP Relay allows a DHCP client to obtain an IP address lease from a DHCP server that is not on the same subnet by intercepting and forwarding DHCP messages between DHCP clients and DHCP servers.
Using a central DHCP server with local DHCP Relays also provides better control and visibility over the network, as all IP address leases are managed from a single location.
After understanding the initial DORA process facilitated by DHCP Relay in almost all customer environments, let's delve into what happens during the renewal phase.
At T1 (50% of the overall lease time), the client sends a renewal request directly to the DHCP server (unicast, port 68-67), bypassing the Relay agent.
At T2 (87.5% of the lease time), the Relay agent intercepts the client's renewal request and forwards it to the DHCP server (unicast, port 67-67).
It's also worth noting that the source port differs during these two stages.
Azure natively provides DHCP services to all virtual networks created within an Azure subscription. The DHCP service is automatically enabled for each virtual network.
A native service running on Azure hypervisors is taking care of the DHCP functions for a given virtual network.
Until recently, the official stance on custom DHCP services in Azure was that they were not supported neither for providing IP addresses to on-premises clients nor for Azure virtual machines deployed in an Azure virtual network.
DHCP traffic has indeed faced 2 main limitations in Azure:
Previously, different workarounds were proposed to customers who required custom DHCP solutions in Azure due to the lack of support for such solutions:
Recently, rate-limiting for DHCP relayed traffic has been removed, enabling the support of the DHCP-relay based solution in Azure.
Please note that this is not expected to affect in any way the successfulness of the DHCP renewal process.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.