The Dynamic Host Configuration Protocol (DHCP) is a means of automatically distributing essential network configuration data to PCs connected to large networks. The settings that are automatically distributed are typically:
The configuration is not distributed on a once-and-for-all basis, but for a fixed time period, known as the DHCP lease, which typically varies from a few hours to a few days. Once the lease time has expired, the configuration might stop working. It is the responsibility of the PC's operating system to renew the lease periodically. If a lease is not renewed before it expires, the DHCP system is free to reallocate the previously leased IP address to someone else, if necessary. If a lease is renewed before it expires, then it is almost always the case that the same configuration is obtained as in the old lease.
The network configuration data listed above could in principle be set manually by the user, or by an installer program, but ISPs prefer to use DHCP to allocate addresses dynamically. This is because ISP's networks are subject to growth and re-organisation, which might require some customer PCs to be assigned new addresses. For instance, consider a neighbourhood of cable customers, all having IP addresses on the same shared sub-net (e.g. 62.253.123.xxx). As more customers subscribe to the service, it will eventually become necessary to divide the neighbourhood geographically into two, each on different sub-nets (e.g. 62.253.201.xxx and 62.253.202.xxx) and every customer's IP address needs to be changed. This is not feasible if customers configure their own addresses manually, so the ISP will use DHCP to distribute addresses automatically.
See Finding the DHCP server address(es).
The D in DHCP stands for Dynamic, so the allocated IP address can in principle change. A change of IP address is frustating to those who wish (for instance) to connect to their home PC from elsewhere. As described above, if a DHCP lease is renewed before it expires, then almost always the same address is renewed (if this were not so, then any open IP connections at the moment of lease renewal would be broken, and lease renewals can happen at any time). The only time a change of IP address might occur at lease renewal is when the ISP's network is being reorganised (e.g. during resegmentation of a cable network), or after a major breakdown.
So one strategy for keeping the same IP address for as long as possible is to leave the cable modem powered on continuously, and leave the PC powered on continuously (don't even let it drop into System Standby: you can let it spin down the hard disk and blank the display, but both the processor and the network interface must be kept active and not allowed to go to standby or sleep). If you are wanting to accept incoming connections, you would need to have the PC on all the time anyway.
If you have a NAT router connected to the cable modem, then it is the NAT router which leases the WAN IP address from the ISP, and so it is the NAT router which has to be left powered on continuously to keep the lease renewed. This is usually easier to arrange than keeping a PC powered on continuously, because the NAT routers are small silent devices and use little power.
However, what happens if you do power off your systems, and switch them on again a day or two later? Will you get the same IP address back as you had before? The answer is that often you will get the same address back, but it is not guaranteed. The DHCP server identifies you by the unique MAC address of your PC's network interface connected to the cable modem, and it maintains a record of which IP addresses it has issued to which MAC addresses. When you power off your PC and fail to renew the DHCP lease, your old IP address remains linked to your MAC address in the DHCP server's records, but it is available for re-allocation to someone else if the DHCP server runs out of spare IP addresses. So, if your area is short of spare IP addresses, you might not get the same IP address back the next time you go online, if that address has been given to someone else. On the other hand, if your area has plenty of spare IP addresses, you might be able to power off for many days and still get the same address back when you go back online. It's all a matter of chance.
If you want a way of addressing your PC at home which is not subject to the whim of a DHCP server, then you should investigate a Dynamic DNS service.
A DHCP failure is often the first visible symptom of an underlying problem: in other words, often the problem is not actually a DHCP problem. The majority of users' problems with DHCP (such as inability to acquire or renew a lease, suffering disconnection every few hours, etc) are caused by one of the following:
The trouble-shooting procedures listed elsewhere on this site sometimes require you to release and/or renew a DHCP lease. A simple method of requesting a new DHCP lease is to re-boot the PC, but that is disruptive and time consuming. It is possible to force a DHCP lease renewal during normal service without a re-boot. Before doing this, you should ensure that all applications which might have network connections open (e.g. e-mail) are closed. Alternative methods for some operating systems are as follows. If you are trying to release the DHCP lease and not renew it, just stop after the release stage of these methods, and don't continue with the renew.
Windows 9x/ME (though the GUI):
Windows 98/ME (by command line):
Windows NT/2000/XP (by command line):
Windows XP (through the GUI):
Apple Mac OS 8.x/9.x:
Apple Mac OS X (through the GUI):
Apple Mac OS X (by command line):
Although restarting usually relinquishes the DHCP lease, and requests a new one, with some versions of the Mac OS 8.6/9.x, this doesn't happen: the Mac continues using whatever network configuration it had when it closed down. Also, when the Mac shuts down, the DHCP lease is left dangling. See http://docs.info.apple.com/article.html?artnum=30994 for more info.
To cure this problem, install the special TCP/IP Options control panel. It is located on the system CD-ROM in the folder :CD Extras:Network Extras:OTExtras:TCP/IP. Drag and drop TCP/IP Options from that folder to the :System Folder:Control Panels folder on hard disk, then restart. Then:
Now, shutdowns will relinquish the DHCP lease, and startups will do a full DHCP discovery.
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.
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.
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.
If you have a PC that can be booted into various different operating systems (e.g. Windows and Linux), you sometimes find that you get allocated different IP addresses in some or all of the systems, but in a consistent way: you usually get one address in Linux, and another in Windows. The disadvantage of this is that the longer you spend in one system, the less likely it is that you will be able to reclaim your normal IP address for the other system: the longer an IP address is idle and unleased, the more likely it is to be allocated to someone else.
The reason for this is that the IP address issued to you by the DHCP server is influenced by a client_id sent in your PC's DHCP request. Windows sends one client_id, and Linux sends another, so the DHCP server allocates different IP addresses even though your MAC address is the same in both cases.
If you can arrange for all your operating systems to send the same client_id, then you would get the same IP address when you boot into any of your systems. The chances of changing the client_id sent by Windows is small, but Linux DHCP clients can be configured to match Windows as follows.
Windows DHCP clients specify a client_id consisting of a type byte of 01 followed by the six-byte MAC address of your PC's ethernet/USB interface.
Some Unix DHCP clients, such as dhclient (from www.isc.org), allow the client_id to be configured. Others, such as the versions of pump used by many Linux distributions, do not. However, pump-0.8.11 or higher, supplied with RedHat Linux 7.1 and downloadable from ftp.redhat.com, has a new command-line option --win-client-ident to match the Windows behaviour. Download, build and install the new version, then edit the startup script /etc/sysconfig/network-scripts/ifup to add the --win-client-ident option. Reboot, and your PC should now keep the same IP address when it boots under Linux as when it boots under Windows. [Thanks to John Stark for the multi-boot DHCP information].
Return to Index.