Link-local addresses are assigned when a host can’t get an IP address from a DHCP server, and they’re often a sign of network misconfiguration.
Let’s see this in action. Imagine a server that just booted up and is trying to get an IP from the DHCP server.
# On the server, after booting
ip addr show eth0
If the server is configured for DHCP and can’t reach one, you’ll see something like this for eth0:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:1a:2b:3c:4d:5e brd ff:ff:ff:ff:ff:ff
inet 169.254.10.20/16 brd 169.254.255.255 scope link eth0:0
inet6 fe80::21a:2bff:fe3c:4d5e/64 scope link
valid_lft forever preferred_lft forever
Notice the inet 169.254.10.20/16 and inet6 fe80::.../64. This is the system’s fallback. The 169.254.0.0/16 range for IPv4 and fe80::/10 for IPv6 are reserved for Automatic Private IP Addressing (APIPA), also known as Link-Local Addressing. These addresses are automatically configured by the operating system when it fails to obtain an IP address from a DHCP server. The primary purpose is to allow devices on the same local network segment to communicate with each other even without a central IP address assignment service.
The system picks an address within 169.254.0.0 to 169.254.255.255 (for IPv4) or fe80:: to fe80::ffff:ffff:ffff:ffff (for IPv6). It uses a process called Duplicate Address Detection (DAD) to ensure the chosen address isn’t already in use on the local link. It essentially broadcasts a Neighbor Solicitation for the address it wants to use. If it receives a Neighbor Advertisement back, it knows the address is taken and tries another one. This happens for both IPv4 and IPv6.
This system solves the problem of isolated devices on a local network segment. If you have a small, isolated network of machines that don’t have a DHCP server, they can still talk to each other. For example, if you have a couple of development machines connected directly with an Ethernet cable, and no router or switch with DHCP, they’ll assign themselves link-local addresses and can ping each other.
The key levers you control are primarily the network interface configuration and the presence/reachability of a DHCP server. If a client is configured to use DHCP, and it can’t reach a DHCP server (or the server is misconfigured and doesn’t respond), it will fall back to link-local.
The IPv6 link-local address generation is a bit more structured. It typically takes the MAC address of the interface, transforms it into EUI-64 format (inserting FFFE in the middle and flipping the 7th bit), and then combines that with the fe80:: prefix. For example, a MAC of 00:1A:2B:3C:4D:5E becomes 021A:2BFF:FE3C:4D5E (the 00 becomes 02 because the second bit is flipped), resulting in fe80::21a:2bff:fe3c:4d5e/64. The /64 means the first 64 bits are the network prefix (fe80::/10 and the EUI-64 part), and the last 64 bits are the host identifier.
The surprise is that these addresses are not routable. They only work on the local network segment (the same broadcast domain). So, a machine with a 169.254.x.x address can’t reach anything beyond its immediate network connection without a router to provide a "real" IP address. This is why seeing these addresses often points to a problem: either no DHCP server is available, or the network is segmented in a way that prevents clients from reaching the DHCP server.
When a host is configured to use DHCP and fails to get an address, it will try to assign itself a link-local address. If it succeeds in getting a DHCP address later, it will drop the link-local address.
The next problem you’ll likely run into is troubleshooting why a device isn’t getting a DHCP address, which often involves checking network cables, switch configurations, and DHCP server logs.