An IPv4 host's interface shows 169.254.37.12/16 instead of its usual address; what does that address signal, and how did the host choose it?
answer
- nobody handed out an address
- self-assigned, link-scoped
- pseudo-random pick, then probe
- routers must not forward it
basics
~20 sIt is an RFC 3927 IPv4 link-local address: the host obtained no address from DHCP or manual configuration and assigned itself one. It picked a pseudo-random address, confirmed it was free with ARP probes, and can reach only hosts on its own link.
solid answer
~40 s`169.254.0.0/16` is the IPv4 **link-local** block defined by RFC 3927. Many host implementations configure such an address when DHCP produces no lease, so the practical reading is "this host never got its configured address": the DHCP server, a relay or the link toward them is not working for this host. Under RFC 3927 the host picks an address pseudo-randomly between `169.254.1.0` and `169.254.254.255`, sends three ARP probes to check nobody owns it, then announces it with two ARP announcements and keeps defending it. Routers **must not** forward packets with a link-local source or destination, so the host can talk to neighbours on the same link and nothing beyond it. RFC 3927 also says the DHCP client must keep running unchanged, so the host can move to a routable address once a server answers.
go deeper
Recognise 169.254.x.x on sight as a self-assigned link-local address and say what it means: no DHCP lease, so only neighbours on the same link are reachable.
Walk through RFC 3927's claim procedure: pseudo-random choice in 169.254.1.0 to 169.254.254.255, three ARP Probes, two announcements, ongoing defence, and why routers must not forward it.
Turn the symptom into a diagnosis: one host versus a whole segment, server versus relay versus VLAN, and remember that the DHCP client keeps retrying so a fix shows up without a reboot.
Weigh whether link-local fallback helps or hides failures in your environment, and make sure monitoring alerts on hosts sitting in 169.254 rather than leaving users to discover it.
## What the address tells you An address in **169.254.0.0/16** is an **IPv4 link-local address** (RFC 3927, Standards Track). It exists so that hosts on one link can talk to each other when there is no DHCP server and nobody configured them by hand: two laptops joined by a cable, a printer on an unmanaged segment. Seeing one on a machine that normally has a routable address is a diagnostic signal. RFC 3927 says a host should not run a link-local address alongside an operable routable one, and many host implementations self-assign a link-local address when their DHCP exchange produces no lease. So the reading is: **this interface has no working routable configuration**. Typical causes sit on the DHCP path, not in the host: - the DHCP server is down or its pool is exhausted, so no offer arrives; - the host is on a segment with no server and no working relay toward one; - the port or segment is in the wrong VLAN, so the broadcasts reach nobody; - a filter on the link drops the client's or server's messages. One host with a 169.254 address points at that host or its port; a whole segment of them points at the server or relay. ## How the host picks and claims the address RFC 3927 gives a fixed procedure: 1. **Select** an address with a pseudo-random generator, uniformly in `169.254.1.0` to `169.254.254.255` inclusive. The first 256 and last 256 addresses of the /16 (`169.254.0.x` and `169.254.255.x`) are reserved and must not be chosen. The generator should be seeded from something unique to the host, such as its MAC address, so the same host tends to pick the same address every boot; a host may also remember its last address and try it first. 2. **Probe.** After a random wait of up to `PROBE_WAIT`, send `PROBE_NUM` ARP Probes: ARP Requests whose sender IP is all zeros and whose target IP is the candidate address, spaced `PROBE_MIN` to `PROBE_MAX` apart. 3. **Detect conflicts.** If any ARP packet arrives whose sender IP is the candidate, or another host's probe targets the same candidate, the address is in use: pick a new one and start again. 4. **Announce.** Broadcast `ANNOUNCE_NUM` ARP announcements, in which sender and target IP are both the new address, so neighbours drop stale cache entries. 5. **Defend** the address for as long as it is used, because two separate links can be joined later. | Constant (RFC 3927 Section 9) | Value | |---|---| | `PROBE_WAIT` | 1 second (initial random delay) | | `PROBE_NUM` | 3 probes | | `PROBE_MIN` / `PROBE_MAX` | 1 to 2 seconds between probes | | `ANNOUNCE_WAIT` | 2 seconds before announcing | | `ANNOUNCE_NUM` / `ANNOUNCE_INTERVAL` | 2 announcements, 2 seconds apart | | `MAX_CONFLICTS` / `RATE_LIMIT_INTERVAL` | after 10 conflicts, at most one new address per 60 seconds | The rate limit exists to stop an ARP storm when something on the link answers every probe. ## What the host can and cannot reach - **Same link: yes.** It resolves neighbours with ARP and talks to them directly, including hosts that hold routable addresses on that link. - **Anything routed: no.** RFC 3927 says a packet with a 169.254 source or destination **must not** be sent to a router for forwarding, and a router that receives one **must not** forward it, whatever its routing table says and regardless of the TTL. That rule covers multicast too. - **No gateway.** The /16 has no default router, so the internet is unreachable from this address by design. ## Rules around the block - **Not for manual or DHCP use.** RFC 3927 Section 1.6 says 169.254 addresses should not be configured by hand or handed out by DHCP, because that bypasses the probing and defence rules; administrators who want their own local numbering should use RFC 1918 space. - **DHCP keeps going.** Section 1.9 says a host must not change its DHCP client's behaviour because it has a link-local address: no stopped retries, no altered timeouts. When a server answers, the host takes the routable address and drops the link-local one. - **IPv6 is different.** IPv6 requires a link-local address on every interface alongside any others; IPv4 link-local is a fallback for when routable configuration is missing, not a constant companion. Some platforms serve machine metadata on a fixed address inside this block. That is a deliberate use of link scope, and the reason 169.254.0.0/16 belongs on every list of destinations an outbound-request filter must refuse.
- Why does RFC 3927 exclude 169.254.0.x and 169.254.255.x from self-assignment?The first and last 256 addresses of 169.254.0.0/16 are reserved for future use and are allocated only by IETF Standards Action, so a host running the dynamic procedure must choose from 169.254.1.0 to 169.254.254.255. That leaves 254 x 256 = 65,024 candidate addresses on a link.
- Two hosts on the same link pick the same 169.254 address at the same moment. What happens under RFC 3927?Each host is probing with an ARP Probe whose target is the shared candidate. When a host sees another host's probe for its candidate from a different hardware address, it treats that as a conflict, chooses a new pseudo-random address and probes again. Seeding the generator from the MAC address makes it unlikely that both pick the same next address.
- Can a host with a 169.254 address talk to a printer that has a routable address on the same switch?Yes. RFC 3927 allows link-local and routable hosts on one link to communicate directly: the sender ARPs for the destination and sends the frame on the link. What fails is anything that would need a router, because link-local packets must not be forwarded.
saying these in an interview costs you the question
- A 169.254 address means the host has a valid lease from a DHCP server.
- Routers forward 169.254 traffic like any private address once a route exists.
- A host may pick any address in 169.254.0.0/16, including 169.254.0.1.
- Handing out 169.254 addresses from a DHCP pool is a fine way to number a lab.
- Once a link-local address is set, the host stops trying DHCP.