Dynamic Configuration of IPv4 Link-Local Addresses
Extracted elements (31)
ARP replies containing a Link-Local sender address are broadcast rather than unicast so that conflicting hosts can detect each other's packets. Without broadcast replies, two hosts (A and B) each using the same address could both reply to a third host's ARP request without either A or B ever learning of the other's conflict.
Hosts SHOULD NOT send periodic gratuitous ARPs to proactively detect conflicts. Doing so wastes bandwidth, and if network segments are only briefly joined and separated before any communication is initiated, the temporary conflict would have been benign; an unnecessary forced reconfiguration would serve no purpose.
The PRNG for address selection should be seeded using the MAC address rather than the real-time clock. A group of hosts powered on simultaneously with clock-seeded PRNGs would generate the same pseudo-random sequence, causing never-ending conflicts as they move in lock-step through identical address choices.
A device implementing both IPv4 Link-Local and a DHCPv4 client MUST NOT alter DHCPv4 client behavior to accommodate Link-Local configuration. Configuring a Link-Local address is not sufficient reason to unconfigure a valid DHCP lease, stop DHCP acquisition, or change DHCP timeouts or state machine behavior.
This specification applies to IEEE 802 LANs (Ethernet, Token-Ring, 802.11 wireless) and other link technologies operating at ≥1 Mbps with ≤1 second round-trip latency that support ARP. Technologies with lower rates or higher latencies may need different values for probing and announcement constants.
A host MUST respond to a conflicting ARP packet (one whose 'sender IP address' matches the host's configured address but whose 'sender hardware address' does not match) either by immediately reconfiguring a new address, or by defending once with a broadcast ARP announcement. A host MUST NOT ignore conflicting ARP packets.
A host MUST test whether a selected IPv4 Link-Local address is already in use before using it. Specifically, before using the address as a source address in any IPv4 or ARP packet, the host MUST perform ARP probing as described in Section 2.2.1.
A host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface simultaneously. When an operable routable address becomes available, the host MUST use it for new communications and MUST cease advertising the Link-Local address.
A router MUST NOT forward a packet with an IPv4 Link-Local source or destination address, irrespective of the router's default route configuration or routes obtained from dynamic routing protocols.
After successfully claiming an address, a host MUST announce it by broadcasting ANNOUNCE_NUM (2) ARP announcements spaced ANNOUNCE_INTERVAL (2) seconds apart, to clear stale ARP cache entries on the link.
All ARP packets (replies as well as requests) that contain a Link-Local 'sender IP address' MUST be sent using link-layer broadcast instead of link-layer unicast. This enables timely duplicate address detection, particularly when previously separated network segments are joined.
An IPv4 packet whose source or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it regardless of the TTL value. This also applies to multicast packets with a Link-Local source address.
During probing, if any ARP packet with a 'sender IP address' matching the probed address is received, the host MUST treat that address as in use and select a new pseudo-random address. Additionally, if an ARP Probe targeting the same address with a different hardware address is received, the host MUST also select a new address.
If a host has already defended its address within the past DEFEND_INTERVAL (10) seconds and receives another conflicting ARP packet, it MUST immediately cease using the address and configure a new one. This prevents two hosts from endlessly attempting to defend the same address.
If the number of address conflicts exceeds MAX_CONFLICTS (10), the host MUST limit its probing rate to no more than one new address per RATE_LIMIT_INTERVAL (60 seconds) to prevent catastrophic ARP storms caused by a rogue host answering all ARP probes.
Implementations of IPv4 Link-Local address autoconfiguration MUST expect address conflicts and MUST be prepared to handle them gracefully by automatically selecting a new address. This requirement applies during the entire period a host uses a 169.254/16 address, not just during initial configuration.
IPv4 Link-Local addresses MUST NOT be configured in the DNS, and DNS clients MUST NOT send queries for names within the '254.169.in-addr.arpa.' domain. DNS recursive servers receiving such queries MUST by default return RCODE 3.
The 169.254/16 address prefix MUST NOT be subnetted. The ARP-based conflict detection mechanism relies on link-layer broadcasts that are not forwarded; subnetting would allow address conflicts to go undetected across subnet boundaries.
The pseudo-random number generation algorithm used for address selection MUST be chosen so that different hosts do not generate the same sequence. The PRNG SHOULD be seeded using a host-unique value such as the IEEE 802 MAC address. Seeding from the real-time clock is NOT suitable.
The 'sender IP address' field in an ARP Probe MUST be set to all zeroes to avoid polluting ARP caches on the link in the case where the address is already in use. The 'target IP address' MUST be set to the address being probed.
When a destination address is in the 169.254/16 prefix, the sender MUST ARP for the destination and send the packet directly on the same physical link. The host MUST NOT send a packet with an IPv4 Link-Local destination address to any router for forwarding.
If IPv4 Link-Local addresses are derived from a hash of the MAC address, they could be indirectly associated with an individual and used to track that person's activities. However, as long as Link-Local addresses do not leave the local link, they reveal no more than direct observation of hardware addresses would.
An ARP Announcement is an ARP Request identical to an ARP Probe except that both the 'sender IP address' and 'target IP address' fields are set to the host's newly selected IPv4 address. It is broadcast on the local link to clear stale ARP cache entries.
An ARP Probe is an ARP Request broadcast on the local link with the 'sender IP address' field set to all zeroes and 'target IP address' set to the address being probed. The 'sender hardware address' must contain the interface's hardware address; the 'target hardware address' should be set to all zeroes.
IPv4 Link-Local addresses are drawn from the 169.254/16 prefix, specifically 169.254.1.0 to 169.254.254.255. The first and last 256 addresses (169.254.0.x and 169.254.255.x) are reserved for future use and must not be selected by dynamic configuration. This gives 65024 usable addresses.
Timing constants govern the claim-and-defend process: PROBE_WAIT=1s, PROBE_NUM=3, PROBE_MIN=1s, PROBE_MAX=2s, ANNOUNCE_WAIT=2s, ANNOUNCE_NUM=2, ANNOUNCE_INTERVAL=2s, MAX_CONFLICTS=10, RATE_LIMIT_INTERVAL=60s, DEFEND_INTERVAL=10s. These are not user-configurable.
IANA has allocated the prefix 169.254/16 for IPv4 Link-Local address use. The first and last 256 addresses (169.254.0.x and 169.254.255.x) are allocated by Standards Action per BCP 26. No other IANA services are required by this document.
An on-link attacker can issue spoofed ARP packets to force a victim host to break all TCP connections by triggering address reconfiguration. The attacker can also prevent the victim from ever completing address selection. When a host abandons an address, another node can hijack existing TCP connections by claiming that address.
The ARP protocol is insecure; a malicious on-link host may send fraudulent ARP packets to interfere with other hosts, including answering all ARP probes to prevent legitimate hosts from ever acquiring an address or cause them to loop infinitely through address selection.
Address claiming proceeds through: (1) wait PROBE_WAIT random delay, (2) send PROBE_NUM ARP Probes spaced PROBE_MIN–PROBE_MAX seconds apart, (3) wait ANNOUNCE_WAIT seconds after last probe with no conflict, (4) broadcast ANNOUNCE_NUM ARP Announcements. On conflict at any stage, select a new address and restart; after MAX_CONFLICTS, rate-limit to one attempt per RATE_LIMIT_INTERVAL.
Conflict defense state: upon receiving a conflicting ARP, the host may (a) immediately reconfigure, or (b) defend once with a broadcast ARP announcement if no conflict was seen within DEFEND_INTERVAL seconds. On a second conflict within DEFEND_INTERVAL, the host MUST immediately reconfigure, preventing an endless mutual-defense loop.