You know those funny IP addresses beginning with 169.254 you see from time to time on systems or in DNS? They have an even funnier name — APIPA, which stands for Automatic Private IP Addressing. And while they may seem both funny sounding and innocuous, the fact is they can be causing problems on your network ranging from delayed logons to intermittent failures. Odds are good you have at least some of them out there on your network causing your users some problems. In this post, we will look at what an APIPA IP address really is, what it was meant for, why it’s happening on your network, and what you can do about it.
What is APIPA?
The IETF reserved the 169.254.0.0/16 block of IPv4 addresses to use for link-local IP address assignment, and codified this in RFC 3927. They also cover IPv6 link-local addressing in RFC 2462, and allocated the fe80::/64 subnet to this, but that’s not used for APIPA.
Why is APIPA there?
Microsoft included support for APIPA in its operating systems starting with Windows 98, with the noble intent of providing a way for systems to communicate with one another on a LAN when services like DHCP did not exist. Microsoft has a KB article, 220874, that defines three cases where APIPA can be useful.
- No Previous IP Address and no DHCP Server
- Previous IP Address and no DHCP Server
- Lease Expires and no DHCP Server
Any Windows host today will automatically provision an APIPA address when the following is true.
- The DHCP Client service is running, which is the default setting and also necessary to dynamically register with DNS.
- A NIC has a link but not a statically configured IP address.
- DHCP Discover broadcasts receive no response.
When that happens, the operating system will choose a random IPv4 address in the 169.254.0.0/16 range, ARP it, and if it receives no reply to the ARP request, provision that on the NIC in question. If the operating system has another NIC that is bound with valid information, and all other defaults are in place, it will register not only its valid address, but the APIPA address, in DNS.
What good is it?
Honestly? Outside of labs specifically designed to teach about APIPA, I only ever implemented it once, back in 2000, for a field station that had a bunch of machines in a workgroup, and no network resources other than a machine with a shared Internet connection. With no server, it seemed to be an acceptable way to let the machines connect to one another, and discover the proxy through WPAD. Less than a year later, I put up a server with DHCP services, DNS services, file and print, and more. I’ve never seen it implemented anywhere else intentionally, and with good effect. But if you have, please leave a comment below and share some knowledge!
Why is it happening to me?
APIPA? On my network? It’s more likely than you think. Ask yourself the following questions.
- Do my servers have multiple NICs?
- Does my datacenter team plug my servers in to their switches?
- Is there any VLAN on which I do not run DHCP?
- Does my DNS support dynamic updates?
If you answered yes to all four questions, then you probably have some systems that not only have APIPA addresses but have registered them in DNS. And that means, the way DNS round-robin works, some of the time a client is going to try to connect to the 169.254.y.z address that is completely unreachable, and that connection attempt has to time out before it will try a valid ip.addr. The more resources, such as domain controllers, you have registering APIPA addresses, the more often this can happen. And at least once in a while, a client will get multiple APIPAs in the DNS response before it gets a valid address, making whatever connection they require take even longer.
When it comes to AD related functions, clients whose IP address is associated with an Active Directory site may never see this as an issue, since the 169.254/16 won’t be associated with a site. But clients on subnets not associated with a site will very likely get an APIPA address in response to a query for a domain controller, and that will cause delays in logon, logon script processing, GPO processing, and more. And who among us can claim that ALL of the IP subnets in use on our network are associated with a valid AD site? Non-site-aware activities, like connecting to shares or mapped drives, will impact everyone equally, with the odds dependent upon the number of names registered in DNS. A single server, by name, with one good NIC and one APIPA NIC, will register each IP address in DNS, so clients will try to hit the APIPA address half the time. They will eventually fail, and try the other, so this will manifest as things being “slow,” not things being misconfigured.
What should I do?
First, go look in DNS to see if you have any 169.254/16 addresses registered. If you do, you must first eliminate the source of the APIPA registration, then delete the invalid entry from DNS. How can you eliminate it? One of the following should work, depending on your needs.
- Disable all NICs on a server that are connected, but not in use.
- Assign a static, valid IP address to every NIC on a server.
- Deploy DHCP scopes to every subnet.
- Disable APIPA behavior on all your servers, by deploying the registry key documented here.
Will APIPA destroy your network? No, of course not. Will it lead to intermittent issues and a general sense of slowness? Absolutely. Should you address this issue? You betcha! With the information above and the options you have, it should be an easy fix that will make everything better.
Go do it!
Photo credits: Collin Anderson, Endaargaanweweer, Barcex
