No laughing matter: APIPA IP addresses can slow your network

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.

APIPA IP address in the system

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.

  1. No Previous IP Address and no DHCP Server
  2. Previous IP Address and no DHCP Server
  3. 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.

  1. Do my servers have multiple NICs?
  2. Does my datacenter team plug my servers in to their switches?
  3. Is there any VLAN on which I do not run DHCP?
  4. 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?

Start fixing APIPA issues at the NIC levelFirst, 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.

  1. Disable all NICs on a server that are connected, but not in use.
  2. Assign a static, valid IP address to every NIC on a server.
  3. Deploy DHCP scopes to every subnet.
  4. 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

14 thoughts on “No laughing matter: APIPA IP addresses can slow your network”

  1. Don’t tell people to do this.

    Removing these will break a lot of exchange and hyper-v capability, possibly to the extent of breaking the environment. They are used to proxy communication between servers to allow them to survive a large range of network level failures.

    1. If your _servers_ aren’t set up for static ip.addrs, then IMHO you’ve already got a lot of stuff broken. But that KB talks about how to only disable it on specific adapters. As long as all your DHCP dependent servers’ NICs are all on the same VLAN, you could just disable APIPA on the NICs that are not, and in your scenario that would still be okay. I’ve never seen a scenario where disabling APIPA broken anything, but I have seen dozens of times where leaving it enabled did.

  2. Many routers, access points and other such devices use APIPA, so that you can connect to them for setup or as a fall-back, should you have forgotten the device address.

    1. Really? Which? I have only used Cisco/Linksys, D-Link, TP-Link, and Aruba in the past few years. I’ve seen them all use a mini-DHCP to set up and have never run into this. Please let me know where you’ve seen that, and other readers please do chime in on those you have seen too. Of course, would you really be using _a server_ to set those up? I only advocate turning this off on servers, so if you’re using a workstation for this, you would still be okay.

  3. 192.168.254.1 | IANA private address Hi-jacking my first tracert hop ?
    ____________________________________
    Could someone there help me with this?
    I need an internet expert to solve this puzzle !

    I have a single Win 7 PC, DIALUP, no network [ I disabled the NIC ],
    NO ROUTERS, 1 visible user [owner/admin].
    Had same problem on same machine before installing Win7 over XP SP2.
    ___________________________________________
    A couple of months back, I noticed that, suddenly, my tracert queries are all showing 192.168.254.1
    as the first hop, instead of my IP being the first hop as it used to be.

    Whois shows that IP as an IANA Private Address.

    Please explain why my queries are now routed through this IP, and who and how someone went about
    doing this.
    Also would like to know what I have to do to stop this first hop.
    Host file does no good.
    3rd party firewall-blocker does no good.

    I dug this up on the internet:
    ” 25.2 Special IP Addresses
    Some special-purposes IP addresses are never used on the open Internet. 192.168.0.0 through 192.168.255.255 are private addresses perhaps used inside a local LAN that does not communicate directly with the Internet. “

    1. Tex – 192.168.x.x is a private IP address as you were told. That’s correct. The solution is plugging your computer directly into your modem and not a router and then you will bypass the 192.168.x.x address. There is no way around it otherwise. This is not relevant to the post about APIPA IP addresses, though. 169.254.x.x is a broken IP, and 192.168.x.x is what the first hop should be. Nothing is wrong with your configuration. The internet is working as it should.

  4. Tex – 192.168.x.x is a private IP address as you were told. That’s correct. The solution is plugging your computer directly into your modem and not a router and then you will bypass the 192.168.x.x address. There is no way around it otherwise. This is not relevant to the post about APIPA IP addresses, though. 169.254.x.x is a broken IP, and 192.168.x.x is what the first hop should be. Nothing is wrong with your configuration. The internet is working as it should.

  5. Tamar,
    Thanks for the reply.
    However you must have missed what I said about not having a ROUTER, o
    or net work. I have a NIC Ethernet connection on the mack of the MoBo,
    but nothing is plugged in to it. I am plugged straight in to a USB dialup modem.
    Phone line straight in to a ZOOM USB Model 3095 modem which goes
    straight in to a USB port on my PC. There is no network configured on
    my PC.
    Any ideas why and HOW my tracert queries are being routed through
    the 192.168.254.1 IANA private address, and HOW to stop whoever /
    whatever is doing it?
    Thanks.

    1. Dial up is still a network. You are dialing into SOMEONE’S network. Your dial up adapter is being assigned an IP address. The 192.168.254.1 is address of the dial up “router” you are hitting.

      Nothing nefarious is happening.

  6. We have a remote, isolated network that is just a camera and a data logger. The location is powered by batteries and solar, so we needed as little power consumption as possible. The devices are statically assigned 169.254.x.x addresses. We did this because when we bring a laptop out to realign the camera, the laptop can use an APIPA to communicate with those devices. Users are blocked from making any network changes, so APIPA is the only solution here.

  7. Hi Casper, I am wondering if 169.254.x.x is being used to hack my sql server database on Windows 2008 R2. When I look at my Windows Firewall logs I see hundreds of thousands of entries that are listed with the source and destination ip address the same. They begin with 169.254.x.x and they are using port 1433. When I do a tracert I get the following result:-
    Tracing route to HOST1 [169.254.x.x]
    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms HOST1 [169.254.x.x]

    Trace complete.

    Although I have blocked this ip address on Windows Firewall for all inbound and outbound ports, it is still communicating through port 1433.

  8. We use APIPA for our phone system, it is non configurable and has to use it to communicate with the Hybrid Analog/IP PBX even though the phones themselves have a non APIPA address assigned to them as well for management.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top