When a PC is powered up, it doesn't know the address of the DHCP server, so it can't talk to it, and the PC itself doesn't have an IP address, so it can't receive any replies anyway. So how does the PC manage to get the DHCP process started?
The answer is that the very earliest stages of DHCP Discovery are done by broadcast in both directions. The PC broadcasts (to IP address 255.255.255.255) a request for any DHCP server to reply, with a random number in the request. In a cable network, this broadcast is picked up by the UBR at the cable ISP's head-end. The UBR is not itself a DHCP server, but acts as a DHCP Agent (see RFC 2131). The DHCP Agent passes the PC's request to the real DHCP server elsewhere in the ISP's network. The DHCP server constructs a reply packet, including the same random number as in the request, and sends it back to the DHCP Agent in the UBR. The UBR then broadcasts the reply into the local cable network downstream (so that every connected PC receives it!). Our PC listens on the network for DHCP replies, and when it sees one with the same random number as it first sent, it takes the reply in and extracts the configuration data from it.
It is the stage of the broadcast reply from the UBR DHCP Agent which causes most problems with user-configured firewalls, particularly when a PC re-awakes after Standby. On re-awakening, the PC reverts to broadcast DHCP discovery, and the reply from the UBR DHCP Agent can appear to be a hostile probe, which is blocked, because the firewall is already installed and running. See Personal Firewall Configuration for Cable Modems for instructions for avoiding this problem.
One of the configuration items is the IP address of the real DHCP server, so that all future DHCP transactions, including periodic lease renewals, can be sent directly to the real DHCP server, not by broadcast.
16-03-09, 02:59 PM
DHCP Process Model
