Initial DHCP discovery
A basic DHCP exchange will on the local subnet appear as follows:
UDP 0.0.0.0:68 (00:00:39:1C:0C:32) >
255.255.255.255:67 (FF:FF:FF:FF:FF:FF) DHCP DISCOVER
At this point the client has no IP address and so uses a source address of 0.0.0.0 and source port of 68 (often referred to as bootpc, the BOOTP client port - BOOTP being the forerunner of DHCP). The packet is sent as a UDP broadcast on port 67 (bootps). Normally this packet will be seen by any host on the local subnet.
Because the OUCS DHCP Service has two servers acting for many different subnets, the packets must be passed from the local subnet to the servers at OUCS. This is done at the router, which will forward any broadcast packet received on an interface to the central DHCP servers (163.1.2.2 and 129.67.1.2: any change to their IP addresses will be announced in advance on the itss-announce mailing list). The forwarding is performed as unicast packets from the router to each server in turn.
Server response: DHCP offer
Because the central DHCP service is provided by two DHCP servers, normally a client will receive two offers of an IP address in response to its initial DISCOVER request. There are exceptions if one server is down, or has no free addresses available.
Because the DHCP servers see the request as originating from the router address, they will return it to the router interface on the subnet in question. The router is responsible for forwarding the responses to the client. For a client on the 163.1.14.0/255.255.254.0 subnet, the responses will be along the following lines:
UDP 163.1.15.254:67 (00:D0:BC:00:11:22) >
163.1.15.99:68 (00:00:39:1C:0C:32) DHCP OFFER
UDP 163.1.15.254:67 (00:D0:BC:00:11:22) >
163.1.15.94:68 (00:00:39:1C:0C:32) DHCP OFFER
Note that the destination IP address is that which the server is offering to the client while the destination MAC address is that of the client's network interface. Thus the packet will reach the client even though it does not yet have its IP address.
Client response: DHCP request
This stage is similar to the first, except that the client now requests a particular IP address from the DHCP server. Additionally, some clients will use this method to request the IP address they previously used (for instance last bootup); if it is denied (DHCP NAK) they will fall back to the first stage.
UDP 0.0.0.0:68 (00:00:39:1C:0C:32) >
255.255.255.255:67 (FF:FF:FF:FF:FF:FF) DHCP REQUEST
Server completion: DHCP acknowledgement
Here the server acknowledges the client's request for an IP address. The basics of the packet are the same as for a DHCP OFFER. Once a client receives this packet, it keeps the IP address given until the expiry of the DHCP lease or until it sends a subsequent DHCP request.
UDP 163.1.15.254:67 (00:D0:BC:00:11:22) >
163.1.15.99:68 (00:00:39:1C:0C:32) DHCP ACK
A variation at this stage is for the server to send a DHCP NAK (not acknowledged) which denies the client the IP address it requested.
DHCP lease renewal
This is similar to the first DHCP REQUEST but with a crucial difference: the client knows its IP address and that of the server. As the DHCP server is on a different subnet, requests bear the MAC address of the router.
UDP 163.1.15.99:68 (00:00:39:1C:0C:32) >
129.67.1.180:67 (00:D0:BC:00:11:22) DHCP REQUEST
UDP 129.67.1.180:67 (00:D0:BC:00:11:22) >
163.1.15.99:68 (00:00:39:1C:0C:32) DHCP ACK
A DHCP NAK may be returned by the DHCP server if the lease cannot be renewed, at which point the client should abandon its IP address (and may send a DHCPDISCOVER).