The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
169.254.0.0/16 addresses explained
By stretch | Wednesday, September 24, 2008 at 12:01 a.m. UTC
Occasionally you may encounter a host which has somehow assigned itself an IP address in the 169.254.0.0/16 range. This is a particularly common symptom of Windows machines which have been configured for DHCP but for whatever reason are unable to contact a DHCP server. When a host fails to dynamically acquire an address, it can optionally assign itself a link-local IPv4 address in accordance with RFC 3927. Microsoft's term for this is Automatic Private Internet Protocol Addressing (APIPA).
The purpose of these self-assigned link-local addresses is to facilitate communication with other hosts within the subnet even in the absence of external address configuration (via manual input or DHCP). Unlike in IPv6, implementation of IPv4 link-local addresses is recommended only in the absence of a normal, routable address. Hosts pseudo-randomly generate the last two octets of the address to mitigate address conflicts. Because of the broadcast nature of some local networking protocols (for example, Microsoft's NetBIOS), hosts may be able to detect one another even without any preexisting knowledge of the address scheme.
However, in practice, these auto-configured addresses tend to do more harm than good, particularly in SOHO networks. Receiving an IP outside of the expected subnet carries more potential for confusion and frustration for end users than does receiving no IP at all.
Posted in Random
September 24, 2008 at 7:15 a.m. UTC
I can't believe that they spent nearly 3 hours about the virtues of APIPA when I took my MCSE a few years ago!
September 24, 2008 at 10:08 a.m. UTC
another /16 network has been consumed with this little play..
September 24, 2008 at 1:53 p.m. UTC
I don't understand this concept at all, it was much better to have a host with no IP at all to facilitate troubleshooting.
September 24, 2008 at 4:53 p.m. UTC
APIPA creates more problems than it solves for me.
September 24, 2008 at 5:12 p.m. UTC
Apple's Bonjour zero-configuration (IETF ZeroConf) networking also uses this range of addresses.
September 24, 2008 at 7:19 p.m. UTC
I loathe Apple's Bonjour service. Why not deploy services with Winamp, mplayer, photoshop, solitaire, minesweeper.... list goes on....
September 25, 2008 at 5:31 p.m. UTC
keep in mind that block has been reserved for a long time...
says "RegDate: 1998-01-27"
May 20, 2009 at 1:21 p.m. UTC
Netcordia's NetMRI also uses this 169.254.0.0/16 address range as it's sole source of network connectivity since it lacks a console port.
May 11, 2010 at 10:30 p.m. UTC
Sounds like comments from a group of non-admins. If you understand what it's for, you can use it to your advantage.
A coworker got a Mac Book and wanted to copy files from his Windows laptop. I plugged a cable between them, and didn't have to touch network settings on either machine. Both automatically use 169.254/16 addresses and can talk to each other.
Just because you don't understand something doesn't mean it's a bad.
December 25, 2010 at 6:56 p.m. UTC
Okay, so this is why my wife's laptop keeps trying to connect to 169.254.0.0. Great. Except it blocks her from connecting to our existing network. SO the next helpful bit would be what to do to stop this misbehavior.
Info was helpful, but without a fix, incomplete...
May 11, 2012 at 5:10 p.m. UTC
If you get this on a wireless LAN, just re-enable your wireless card so it dumps everything and starts again. I travel all the time and it is not unusual for my computer to have this address as we move from hotel lan to hotel lan. In XP, you can REPAIR the wireless and it cures it 99.9% of the time. Does the REPAIR option exist in Win 7??
July 27, 2012 at 8:11 p.m. UTC
It does exist in windows 7 it's just called Trouble Shoot Problems now as well as Diagnose when on status page.
December 5, 2012 at 4:46 p.m. UTC
to use what tpinstl said as a "how not to think" lesson, APIPA is a solution for when DHCP is not available. If you want to talk to other networks, FIX YOUR NETWORK!! In his case DHCP needs to be turned on or fixed in his network, or he should configure an IP on the machine.
December 17, 2012 at 8:09 a.m. UTC
My simple question is this. If I see a host with a 169.254 APIPA does this mean that the host successfully generated a DHCP request?
If the answer is yes, does this mean that the host had information regarding a DHCP server and that DHCP server did not respond?
February 23, 2013 at 4:09 p.m. UTC
@Mike - I don't think so. If I understand correctly the host assigns itself one of these addresses because it's initial DHCP discovery message went unanswered.
For example if you had a few hosts connected to a switch or HUB but did not have manual IP addresses configured on the hosts, and instead had them set to automatically acquire addresses from DHCP, this would let the hosts communicate.
The DHCP request that you are talking about is only generated after the host receives a DHCP offer from the server, which is only generated after the server receives a DHCP discovery message from the host in the first place.
September 29, 2013 at 3:32 a.m. UTC
Say someone, let's call her Eve, wanted information that is held on a certain machine that's connected to the Internet. Could she use the 169.254.0.0 net to gain entry, or is it somehow a protected or secure network?
December 5, 2013 at 12:02 a.m. UTC
@Mike - your question seems to imply a misunderstanding of the DHCP protocol. Unlike TCP protocols, which involve a handshake, DHCP discovery uses UDP, which is more like "fire and forget." Moreover, the DHCP discovery process begins with a simple broadcast to 255.255.255.255. There is no way to know if you were heard unless and until you are respondeds.
It's less like getting a drivers license from the DMV, and more like saying "anybody there?" in a dark room.
August 9, 2015 at 7:08 a.m. UTC
I am working on a set of virtual machines which are related to the Microsoft 20331B course where I am facing this issue ....
The VM with a DC has been assigned with an APIPA address.
The rest of the VMs are also assigned with APIPA addresses.
This results in having the machines not being identified to each other.
Do I need to assign the IP for all clients manually as static? or have I configured my VM's on the Hyper-V incorrectly?
October 30, 2015 at 12:38 a.m. UTC
So my question is, what exactly should you do if encounter this issue and the troubleshoot tool doesn't help you, I have tried restarting the machine at times and it worked but sometimes not. confused
July 24, 2016 at 11:24 a.m. UTC
Thank God for the APIPA. It perfectly works with Raspberry Pi and Windows host.