Custom DHCP support in Azure
Dynamic Host Configuration Protocol (DHCP) is a network protocol used to dynamically assign IP addresses and other network parameters to devices on a network.
How DHCP works
The DORA process
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.
Lease renewal
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.
DHCP Relay
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.
DHCP renewal with Relay
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.
How DHCP works in Azure natively
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.
Historical custom DHCP limitations in Azure
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:
- Broadcast traffic is not supported in Azure. Since many aspects of the DHCP protocol rely on broadcast messages in the direct client-server model, any DHCP packet sent to Azure will fail delivery. As a result, direct client to server communication cannot be honored in Azure.
- While the DHCP-relay based solution may seem like a convenient alternative due to its unicast packet transmission, its effectiveness is limited by historical rate-limiting of DHCP Relay traffic 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:
- custom DHCP deployed in Azure VMware Solution (AVS), as AVS does not rate-limit DHCP relay traffic.
- using an IPSec tunnel between the DHCP Relay and the DHCP server, which hides the relayed traffic from the Azure platform.
Current status
Recently, rate-limiting for DHCP relayed traffic has been removed, enabling the support of the DHCP-relay based solution in Azure.
Limitations:
- Any custom DHCP server in Azure deployed before the rate-limiting removal may have to be redeployed.
- Only UDP 67 > 67 / UDP 68 > 68 has been unblocked. UDP 68 > 67 is still throttled and UDP 67 > 68 (the return) is blocked. Therefore, there will still be NO support for the T1 DHCP Renewals, only T2 renewals will come through.
Please note that this is not expected to affect in any way the successfulness of the DHCP renewal process.
