Automatic Private IP Addressing (APIPA) is a feature that Microsoft first included in Windows 98 and has been present in every one of their operating systems released since. Reaction to it in the IT community has largely been indifferent, even somewhat hostile.
The idea is that DHCP clients, if unable to obtain an IP address from a DHCP server, will instead assign themselves an IP address on the 169.254.0.0 network (with a standard Class B subnet mask of 255.255.0.0). The computers randomly generate numbers for the last two octets and broadcast them to ensure that they’re not already in use. If they are in use, the computer randomly generates two more numbers and broadcasts the new address. The process repeats until the computer generates an address that is unique to that subnet.
At first glance, it seems like a good idea. If DHCP fails, the client machine still gets an IP address. But on second thought, what use is it, since it obviously doesn’t match any of the IP addresses you’re using on your network?
Many network administrators find APIPA not only useless, but also a misleading nuisance when troubleshooting (at first glance, when you run IPCONFIG, it appears that the client has an IP address–until you look at the numbers). As a result, many administrators turn off APIPA.
But wait! APIPA is very useful–provided you take a few additional steps to implement it properly on your network.
Essentially, APIPA is intended to be an alternative to Dynamic Host Configuration Protocol (DHCP) addressing. It could be used instead of DHCP in a Small Office/Home Office environment, but it usually isn’t because of Internet connectivity needs. Where APIPA becomes truly useful is as a backup to a DHCP implementation.
Imagine this scenario: your DHCP server or servers fail and are out of commission just long enough for the IP address leases on the clients to expire. Without APIPA, the clients would have the dreaded 0.0.0.0 non-address and lose all network connectivity. While you’re in the middle of fixing your DHCP server, your phone starts ringing off the hook.
In the same scenario with APIPA implemented, the client computers assign themselves an IP address that will provide Local Area Network connectivity. Something’s better than nothing, right?
How can you take advantage of this? The key is to configure your other network interfaces, especially hard-coded local servers and printers, with additional IP addresses in the same range. For example, suppose you have a file server and a network interface print device on an office LAN. Assign the file server a second IP address of 169.254.1.100 and the printer a second IP of 169.254.1.101.
As a result, users’ computers will still retain network connectivity to local resources if your DHCP servers are unavailable for an extended period of time. In this example, users will still be able to print and to access file shares on the server (provided you also update your DNS servers to include address records for the alternate IP addresses for your servers and printers).
Yes, communications with other subnets and the Internet will be lost, but at least there’s some semblance of a network available. By implementing APIPA properly, you can reduce support issues and lost productivity that result from DCHP failure.
[MOdified by Mitch Tulloch] – 28 Oct 2004
