RFC 3927

Dynamic Configuration of IPv4 Link-Local Addresses

📅 published May 2005, from ietf

RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses 🦋

Part 1 of 8 ✨

Okay bestie, this one's from May 2005, and it's an Internet standards track doc, so it's a real spec people build against 💅. The authors are S. Cheshire (Apple Computer), B. Aboba (Microsoft Corporation), and E. Guttman (Sun Microsystems). Their whole mission is giving hosts an IPv4 address when nobody else will hand one out 🧚. The title block doesn't list anything it obsoletes or updates, so there's no drama with older versions 🙈.

Status of This Memo 📋

This doc is an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and send suggestions for making it better 💖. If you want the official standardization state for this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 🌸.

Copyright Notice ©

Copyright (C) The Internet Society (2005).

Abstract 🌈

Okay so, to be part of wide-area IP networking, a host needs IP addresses on its interfaces. You either type them in by hand or get them automatically from something on the network, like a Dynamic Host Configuration Protocol (DHCP) server 💻. The problem is that address config isn't always available 😭. That's why it's super useful for a host to still be able to do a solid subset of IP networking even with no config at all 🫶.

This doc explains how a host can automatically set up an interface with an IPv4 address from the 169.254/16 prefix, one that works for talking to other devices on the same physical (or logical) link ✨.

IPv4 Link-Local addresses are NOT for devices that aren't directly on the same link 🙅‍♀️. They're only for when stable, routable addresses aren't around, like ad hoc or isolated networks 🍓. This doc does not recommend putting IPv4 Link-Local and routable addresses on the same interface at the same time 💅.

Table of Contents 🗂️

1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  3
    1.1.  Requirements. . . . . . . . . . . . . . . . . . . . . .  3
    1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . .  3
    1.3.  Applicability . . . . . . . . . . . . . . . . . . . . .  5
    1.4.  Application Layer Protocol Considerations . . . . . . .  6
    1.5.  Autoconfiguration Issues. . . . . . . . . . . . . . . .  7
    1.6.  Alternate Use Prohibition . . . . . . . . . . . . . . .  7
    1.7.  Multiple Interfaces . . . . . . . . . . . . . . . . . .  8
    1.8.  Communication with Routable Addresses . . . . . . . . .  8
    1.9.  When to configure an IPv4 Link-Local Address. . . . . .  8
2.  Address Selection, Defense and Delivery . . . . . . . . . . .  9
    2.1.  Link-Local Address Selection. . . . . . . . . . . . . . 10
    2.2.  Claiming a Link-Local Address . . . . . . . . . . . . . 11
    2.3.  Shorter Timeouts. . . . . . . . . . . . . . . . . . . . 13
    2.4.  Announcing an Address . . . . . . . . . . . . . . . . . 13
    2.5.  Conflict Detection and Defense. . . . . . . . . . . . . 13
    2.6.  Address Usage and Forwarding Rules. . . . . . . . . . . 14
    2.7.  Link-Local Packets Are Not Forwarded. . . . . . . . . . 16
    2.8.  Link-Local Packets are Local. . . . . . . . . . . . . . 16
    2.9.  Higher-Layer Protocol Considerations. . . . . . . . . . 17
    2.10. Privacy Concerns. . . . . . . . . . . . . . . . . . . . 17
    2.11. Interaction between DHCPv4 and IPv4 Link-Local
          State Machines. . . . . . . . . . . . . . . . . . . . . 17
3.  Considerations for Multiple Interfaces. . . . . . . . . . . . 18
    3.1.  Scoped Addresses. . . . . . . . . . . . . . . . . . . . 18
    3.2.  Address Ambiguity . . . . . . . . . . . . . . . . . . . 19
    3.3.  Interaction with Hosts with Routable Addresses. . . . . 20
    3.4.  Unintentional Autoimmune Response . . . . . . . . . . . 21
4.  Healing of Network Partitions . . . . . . . . . . . . . . . . 22
5.  Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.  Application Programming Considerations. . . . . . . . . . . . 24
    6.1.  Address Changes, Failure and Recovery . . . . . . . . . 24
    6.2.  Limited Forwarding of Locators. . . . . . . . . . . . . 24
    6.3.  Address Ambiguity . . . . . . . . . . . . . . . . . . . 25
7.  Router Considerations . . . . . . . . . . . . . . . . . . . . 25
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.  Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 26
    10.1. Normative References. . . . . . . . . . . . . . . . . . 26
    10.2. Informative References. . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A - Prior Implementations. . . . . . . . . . . . . . . . 28

1. Introduction 🎀

As IP keeps getting more popular, it's becoming seriously valuable to use familiar IP tools like FTP, not just for global chats but for local ones too 💜. Like, picture two people with laptops on IEEE 802.11 Wireless LANs [802.11] who just want to swap files 📁. They shouldn't have to hand-type static IP addresses or set up a DHCP server [RFC2131] 🙄. Main character energy is letting IP apps just work 💅.

This doc describes a way for a host to automatically set up an interface with an IPv4 address from the 169.254/16 prefix, one that's valid for Link-Local communication on that interface 🦋. It's especially clutch where no other config mechanism exists 🫶. The IPv4 prefix 169.254/16 is registered with the IANA for exactly this purpose 🌸. For IPv6 Link-Local addresses, check "IPv6 Stateless Address Autoconfiguration" [RFC2462] ✨.

Link-Local communication with IPv4 Link-Local addresses only works with devices on the same physical (or logical) link 🔗. It is NOT suitable for devices that aren't directly connected to that same link 🙅‍♀️. Lowkey that's the whole point, so don't forget it 😭.

Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already do this 🍎🪟. This doc is the standardization part, setting rules for how hosts and routers should treat IPv4 Link-Local addresses 📋. In particular, it covers how routers should act when they get packets with an IPv4 Link-Local address as the source or destination 🧚. For hosts, it talks about claiming and defending addresses, keeping Link-Local and routable IPv4 addresses on one interface, and multi-homing issues 💖.

1.1. Requirements 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs" [RFC2119] 💅.

1.2. Terminology 🔍

This doc is all about Link-Local addressing, for IPv4 communication between two hosts on a single link ✨. A set of hosts counts as "on the same link" if both of these are true 🫶:

When any host A from that set sends a packet to any other host B in that set, using unicast, multicast, or broadcast, the entire link-layer packet payload arrives unmodified.
A broadcast sent over that link by any host from that set can be received by every other host in that set.

The link-layer header can get modified, like in Token Ring Source Routing [802.5], but the link-layer payload can't 🙈. Specifically, if any device forwarding a packet changes any part of the IP header or IP payload, the packet is no longer considered to be on the same link 😭. So a packet can go through stuff like repeaters, bridges, hubs, or switches and still count as on the same link for this doc 🌈. A device like an IP router that decrements the TTL or otherwise changes the IP header is a no-go 🚫.

This doc uses "routable address" for all valid unicast IPv4 addresses outside the 169.254/16 prefix that can be forwarded by routers 🌍. That includes global IP addresses and private addresses like Net 10/8 [RFC1918], but NOT loopback addresses like 127.0.0.1 🙅‍♀️.

Anywhere this doc says "host" while talking about IPv4 Link-Local addresses, the same rules apply to routers when they're the source or intended destination of packets with IPv4 Link-Local source or destination addresses 🧚.

Anywhere this doc says "sender IP address" or "target IP address" in the context of an ARP packet, it means the ARP packet fields the ARP specification [RFC826] calls ar$spa (Sender Protocol Address) and ar$tpa (Target Protocol Address) 🎀. For how this doc uses ARP, each of those fields always holds an IP address 💜.

In this doc, an "ARP Probe" is an ARP Request packet, broadcast on the local link, with an all-zero 'sender IP address' 🦋. The 'sender hardware address' MUST contain the hardware address of the interface sending the packet 💅. The 'target hardware address' field is ignored and SHOULD be set to all zeroes 🌸. The 'target IP address' field MUST be set to the address being probed ✨.

In this doc, an "ARP Announcement" is an ARP Request packet, broadcast on the local link, identical to the ARP Probe above, except that both the sender and target IP address fields contain the IP address being announced 📣.

Constants are introduced in all capital letters, and their values are given in Section 9 🔢.

1.3. Applicability ✨

okay so bestie, this spec is for all IEEE 802 LANs 🦋 That means Ethernet [802.3], Token-Ring [802.5], and IEEE 802.11 wireless LANs [802.11], plus [802] itself. It also covers any other link-layer tech that runs at at least 1 Mbps, has a round-trip latency of at most one second, and supports ARP [RFC826]. Wherever this doc says "IEEE 802," the same text applies to all of those networks. 💅

Now the tea ☕ Link-layer techs that support ARP but run below 1 Mbps or have latencies above one second may need different values for some parameters:

(a) the number of, and interval between, ARP probes, see PROBE_NUM, PROBE_MIN, PROBE_MAX defined in Section 2.2.1

(b) the number of, and interval between, ARP announcements, see ANNOUNCE_NUM and ANNOUNCE_INTERVAL defined in Section 2.4

(c) the maximum rate at which address claiming may be attempted, see RATE_LIMIT_INTERVAL and MAX_CONFLICTS defined in Section 2.2.1

(d) the time interval between conflicting ARPs below which a host MUST reconfigure instead of attempting to defend its address, see DEFEND_INTERVAL defined in Section 2.5

Techs that don't support ARP might still have other ways to check whether an IP address is already in use 🤔 But using claim-and-defend stuff on those networks is outside the scope of this doc, so no spoilers there. 🙈

This spec is meant for small ad hoc networks, like a single link with only a few hosts 🌸 Yes, there are 65024 IPv4 Link-Local addresses in theory, but trying to use all of them on one link would mean a really high chance of conflicts. A host would then spend an inordinate amount of time hunting for a free address. Literally forever-vibes. 😭

Network operators with more than 1300 hosts on one link might want to split it into two or more subnets 🧚 Here's why: a host joining a link that already has 1300 hosts, picking an IPv4 Link-Local address at random, has a 98% chance of landing on an unused one on the first try. Within two tries, the chance goes up to 99.96%. The probability that it has to try more than ten times is about 1 in 10^17. Iconic math, honestly. 🔥

1.4. Application Layer Protocol Considerations 🎀

IPv4 Link-Local addresses and their dynamic configuration have huge implications for the apps that use them 😳 This is covered in Section 6. Lots of apps basically assume that the addresses of their peers are routable, don't change much, and are unique. Those assumptions don't hold up with IPv4 Link-Local addresses, or with a mix of Link-Local and routable IPv4 addresses. Not it. 💀

So, while plenty of apps will work fine with IPv4 Link-Local addresses (or a mix of those and routable ones), others might only work after being modified, or will have reduced or partial functionality. Some apps may not be modifiable for these conditions at all, which is just sad. 😔

IPv4 Link-Local addresses should therefore only be used where stable, routable addresses aren't available (like on ad hoc or isolated networks), or in controlled situations where these limitations and their impact on apps are understood and accepted. This doc does not recommend configuring IPv4 Link-Local and routable addresses on the same interface at the same time. Keep those separate, bestie. 🫶

Using IPv4 Link-Local addresses for off-link communication is likely to cause app failures 🚨 This can happen in any app with embedded addresses, if an IPv4 Link-Local address gets embedded while talking to a host that isn't on the link. Examples of apps that embed addresses include IPsec, Kerberos 4/5, FTP, RSVP, SMTP, SIP, X-Windows/Xterm/Telnet, Real Audio, H.323, and SNMP [RFC3027].

To stop IPv4 Link-Local addresses from being used in off-link communication, here are the cautionary measures to follow 👑

a. IPv4 Link-Local addresses MUST NOT be configured in the DNS. Mapping IPv4 addresses to host names is normally done by sending DNS queries for names of the form "x.x.x.x.in-addr.arpa." Link-Local addresses only mean something on the local link, so it's inappropriate to send those queries beyond the local link. DNS clients MUST NOT send DNS queries for any name that falls within the "254.169.in-addr.arpa." domain. 🙅‍♀️

DNS recursive name servers that get queries from non-compliant clients for names within the "254.169.in-addr.arpa." domain MUST by default return RCODE 3, authoritatively saying that no such name exists in the Domain Name System. Shade. 🕶️

b. Names that are globally resolvable to routable addresses should be used within applications whenever they're available 🌈 Names that can only be resolved on the local link (for example, via protocols like Link Local Multicast Name Resolution [LLMNR]) MUST NOT be used in off-link communication. IPv4 addresses and names that can only be resolved on the local link SHOULD NOT be forwarded beyond the local link. IPv4 Link-Local addresses SHOULD only be sent when a Link-Local address is used as the source and/or destination address. This strong advice should keep limited-scope addresses and names from leaving the context they belong to. Boundaries, babe. 🧱

c. If names resolvable to globally routable addresses aren't available, but the globally routable addresses themselves are, they should be used instead of IPv4 Link-Local addresses ✨

1.5. Autoconfiguration Issues 💫

Implementations of IPv4 Link-Local address autoconfiguration MUST expect address conflicts 😤 They MUST also be prepared to handle them gracefully, by automatically selecting a new address whenever a conflict is detected, as described in Section 2. This requirement applies during the entire time a host is using a 169.254/16 IPv4 Link-Local address, not just during initial interface configuration. Conflicts can pop up well after a host has finished booting, for example if two previously separate networks get joined, as described in Section 4. Plot twist. 🎬

1.6. Alternate Use Prohibition 🚫

Heads up: addresses in the 169.254/16 prefix SHOULD NOT be configured manually or by a DHCP server 🙃 Manual or DHCP configuration can make a host use an address in that prefix without following the special rules for duplicate detection and automatic configuration that apply to this prefix. The DHCP spec [RFC2131] says a DHCP client SHOULD probe a newly received address with ARP, but that's not mandatory. Similarly, the DHCP spec recommends that a DHCP server SHOULD probe an address using an ICMP Echo Request before allocating it, but that's not mandatory either. Even if the server does it, IPv4 Link-Local addresses aren't routable. So a DHCP server that isn't directly connected to a link can't detect whether a host on that link is already using the address it wants to hand out. Oof. 😬

Administrators who want to configure their own local addresses (using manual configuration, a DHCP server, or any other mechanism not described in this document) should use one of the existing private address prefixes [RFC1918], not the 169.254/16 prefix 🏠

1.7. Multiple Interfaces 🔌

Hosts that support more than one active interface need extra considerations when one or more of those interfaces support IPv4 Link-Local address configuration 🧩 These are discussed in Section 3. Main character energy with multiple NICs. 💅

1.8. Communication with Routable Addresses 🌍

Sometimes devices with a configured Link-Local address need to talk to a device with a routable address on the same physical link, and vice versa 🦋 The rules in Section 2.6 make that communication possible.

For example, a laptop with only a routable address can browse websites worldwide using its globally-routable address, while also printing those web pages on a local printer that only has an IPv4 Link-Local address 🖨️🌸 Multitasking queen behavior. 👑

1.9. When to configure an IPv4 Link-Local address 🎀

okay so having addresses of multiple different scopes on one interface, with no good way to tell when each one should be used, is total chaos for apps and super confusing for users 😭. A host with an address on a link can talk to every other device on that link, whether those devices use Link-Local addresses or routable ones 🫶. So a host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface. "Operable address" just means an address that works effectively for communication in the current network context (more on that below). When an operable routable address is available on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface. BUT during the transition (in either direction) between routable and Link-Local addresses, both MAY be in use at once, as long as these rules are followed: ✨

The assignment of an IPv4 Link-Local address on an interface is based solely on the state of the interface, and it's independent of other protocols like DHCP. A host MUST NOT change its behavior or its use of other protocols such as DHCP just because it assigned an IPv4 Link-Local address to an interface 💅.
If a host finds that an interface which was previously configured with an IPv4 Link-Local address now has an operable routable address available, the host MUST use the routable address when starting new communications, and MUST stop advertising the IPv4 Link-Local address through whatever mechanisms had made it known to others 🫠. The host SHOULD keep using the IPv4 Link-Local address for communications already underway, and MAY keep accepting new communications addressed to the IPv4 Link-Local address. Ways an operable routable address might become available on an interface include:
- Manual configuration
- Address assignment through DHCP
- Roaming of the host to a network on which a previously assigned address becomes operable
If a host finds that an interface no longer has an operable routable address available, the host MAY identify a usable IPv4 Link-Local address (as described in section 2) and assign that address to the interface 🦋. Ways an operable routable address might stop being available on an interface include:
- Removal of the address from the interface through manual configuration
- Expiration of the lease on the address assigned through DHCP
- Roaming of the host to a new network on which the address is no longer operable

The system deciding whether an address is "operable" is honestly not clear cut 🙈, and lots of changes in the system context (e.g., router changes) can affect whether an address is operable. Roaming from one network to another is likely, but not certain, to change the operability of a configured address, and detecting that move is not always trivial 🥲.

"Detection of Network Attachment (DNA) in IPv4" [DNAv4] goes deeper on address assignment and operability determination, so go check it out if you're curious 🧚.

2. Address Selection, Defense and Delivery 🌸

okay this section explains the IPv4 Link-Local address selection algorithm, how IPv4 Link-Local addresses get defended, and how IPv4 packets with IPv4 Link-Local addresses get delivered 🔥.

Windows and Mac OS hosts that already implement Link-Local IPv4 address auto-configuration are compatible with the rules in this section. However, should any interoperability problem be discovered, this document, not any prior implementation, defines the standard 👑.

2.1. Link-Local Address Selection 🍓

When a host wants to configure an IPv4 Link-Local address, it picks one using a pseudo-random number generator with a uniform distribution in the range from 169.254.1.0 to 169.254.254.255 inclusive 💜.

The IPv4 prefix 169.254/16 is registered with the IANA for this purpose. The first 256 and last 256 addresses in the 169.254/16 prefix are reserved for future use, and a host using this dynamic configuration mechanism MUST NOT select them 🚫.

The pseudo-random number generation algorithm MUST be chosen so that different hosts do not generate the same sequence of numbers 🙅‍♀️. If the host has access to persistent information that's different for each host, like its IEEE 802 MAC address, then the pseudo-random number generator SHOULD be seeded using a value derived from that information. This means that even without any other persistent storage, a host will usually pick the same IPv4 Link-Local address each time it boots, which is convenient for debugging and other operational reasons 🛠️. Seeding the generator with the real-time clock or any other information that is (or may be) identical in every host is NOT suitable for this purpose 😤. Why? Because a group of hosts that all power on at the same time could all generate the same sequence, and then you get a never-ending series of conflicts as they move in lock-step through exactly the same pseudo-random sequence, conflicting on every address they probe. Absolutely not, bestie 💀.

Hosts that have persistent storage MAY record the IPv4 address they've selected, for each interface. On booting, hosts with a previously recorded address SHOULD use that address as their first candidate when probing. This makes addresses way more stable ✨. For example, if a group of hosts is powered off at night, then when they're powered back on the next morning, they'll all resume using the same addresses, instead of picking different ones and maybe having to sort out conflicts 🦋.

2.2. Claiming a Link-Local Address 🫶

After it has selected an IPv4 Link-Local address, a host MUST test whether that address is already in use before it starts using it 👀. When a network interface goes from inactive to active, the host doesn't know which IPv4 Link-Local addresses might be in use on that link, since the point of attachment may have changed, or the interface may have been inactive when a conflicting address was claimed.

If the host started using an IPv4 Link-Local address that another host was already using, that would be disruptive to the other host 😬. Also, since the host may have changed its point of attachment, a routable address might be obtainable on the new network, so it can't be assumed that an IPv4 Link-Local address should be preferred.

Before using the IPv4 Link-Local address (e.g., as the source address in an IPv4 packet, or as the Sender IPv4 address in an ARP packet), a host MUST perform the probing test described below, so it gets better confidence that using the address won't cause disruption 🫡.

Examples of events that involve an interface becoming active include:

Reboot/startup
Wake from sleep (if the network interface was inactive during sleep)
Bringing up a previously inactive network interface
IEEE 802 hardware link-state change (appropriate for the media type and security mechanisms which apply) indicates that an interface has become active.
Association with a wireless base station or ad hoc network.

A host MUST NOT perform this check periodically as a matter of course 🙅‍♀️. That would be a waste of network bandwidth, and it's unnecessary because hosts can passively discover conflicts, as described in Section 2.5 🧠.

2.2.1. Probe details 🔍

On a link layer such as IEEE 802 that supports ARP, conflict detection is done using ARP probes. On link-layer technologies that don't support ARP, other techniques may be available for figuring out whether a particular IPv4 address is currently in use. However, applying claim-and-defend mechanisms to those networks is outside the scope of this document 🙃.

A host probes to see if an address is already in use by broadcasting an ARP Request for the desired address. The client MUST fill in the 'sender hardware address' field of the ARP Request with the hardware address of the interface it's sending the packet through. The 'sender IP address' field MUST be set to all zeroes, so it doesn't pollute the ARP caches of other hosts on the same link in the case where the address turns out to already be in use by another host 🧼. The 'target hardware address' field is ignored and SHOULD be set to all zeroes. The 'target IP address' field MUST be set to the address being probed. An ARP Request built this way, with an all-zero 'sender IP address', is referred to as an "ARP Probe" 💖.

When ready to begin probing, the host should wait a random time interval, picked uniformly in the range from zero to PROBE_WAIT seconds, and then send PROBE_NUM probe packets, each one spaced randomly PROBE_MIN to PROBE_MAX seconds apart ⏳. If during this period (from the start of the probing process until ANNOUNCE_WAIT seconds after the last probe packet is sent) the host receives any ARP packet (Request or Reply) on the interface being probed, where the packet's 'sender IP address' is the address being probed for, then the host MUST treat that address as in use by some other host, and MUST select a new pseudo-random address and repeat the process 🚨. Also, if during this period the host receives any ARP Probe where the packet's 'target IP address' is the address being probed for, and the packet's 'sender hardware address' is not the hardware address of the interface the host is trying to configure, then the host MUST similarly treat this as an address conflict and select a new address as above. This can happen if two (or more) hosts try to configure the same IPv4 Link-Local address at the same time 👯.

A host should keep a counter of the number of address conflicts it has run into while trying to acquire an address. If the number of conflicts goes over MAX_CONFLICTS, then the host MUST limit how fast it probes for new addresses to no more than one new address per RATE_LIMIT_INTERVAL 🐢. This prevents catastrophic ARP storms in pathological failure cases, like a rogue host that answers every ARP probe, which would send legitimate hosts into an infinite loop trying to select a usable address 🌀.

If, by ANNOUNCE_WAIT seconds after the last ARP Probe was transmitted, no conflicting ARP Reply or ARP Probe has been received, then the host has successfully claimed the desired IPv4 Link-Local address 🎉👑.

2.3. Shorter Timeouts ⭐

New network technologies may show up where shorter delays are appropriate compared to what this document requires. A later IETF publication may provide guidelines with different values for PROBE_WAIT, PROBE_NUM, PROBE_MIN and PROBE_MAX for those technologies 🌈.

2.4. Announcing an Address ✨

Okay so once you've probed and found an address nobody else is using, the host MUST then announce its claimed address by broadcasting ANNOUNCE_NUM ARP announcements, spaced ANNOUNCE_INTERVAL seconds apart. An ARP announcement is basically the ARP Probe from earlier, except now the sender and target IP addresses are both set to the host's newly picked IPv4 address. The whole point is making sure other hosts on the link don't have stale ARP cache entries left over from some other host that might've used that address before. 🧹💖

2.5. Conflict Detection and Defense 🛡️

Conflict detection isn't just a select-an-address thing that happens during ARP probing, it's giving ongoing. It stays in effect for as long as a host is using an IPv4 Link-Local address. At any time, if a host gets an ARP packet (request or reply) on an interface where the sender IP address is the IP the host configured for that interface, but the sender hardware address doesn't match that interface's hardware address, that's a conflicting ARP packet, which means there's an address conflict. 👀

A host MUST respond to a conflicting ARP packet in either (a) or (b) below:

(a) Upon receiving a conflicting ARP packet, a host MAY elect to immediately configure a new IPv4 Link-Local address as described above, or
(b) If a host currently has active TCP connections or other reasons to prefer to keep the same IPv4 address, and it has not seen any other conflicting ARP packets within the last DEFEND_INTERVAL seconds, then it MAY elect to attempt to defend its address by recording the time that the conflicting ARP packet was received, and then broadcasting one single ARP announcement, giving its own IP and hardware addresses as the sender addresses of the ARP. Having done this, the host can then continue to use the address normally without any further special action. However, if this is not the first conflicting ARP packet the host has seen, and the time recorded for the previous conflicting ARP packet is recent, within DEFEND_INTERVAL seconds, then the host MUST immediately cease using this address and configure a new IPv4 Link-Local address as described above. This is necessary to ensure that two hosts do not get stuck in an endless loop with both hosts trying to defend the same address. 🔁

A host MUST respond to conflicting ARP packets as described in either (a) or (b) above. A host MUST NOT ignore conflicting ARP packets. 🚫

Forced address reconfiguration may be disruptive, causing TCP connections to be broken. However, it is expected that such disruptions will be rare, and if inadvertent address duplication happens, then disruption of communication is inevitable, no matter how the addresses were assigned. It is not possible for two different hosts using the same IP address on the same network to operate reliably. Not a vibe, bestie. 💀

Before abandoning an address due to a conflict, hosts SHOULD actively attempt to reset any existing connections using that address. This mitigates some security threats posed by address reconfiguration, as discussed in Section 5. 🔒

Immediately configuring a new address as soon as the conflict is detected is the best way to restore useful communication as quickly as possible. The mechanism described above of broadcasting a single ARP announcement to defend the address mitigates the problem somewhat, by helping to improve the chance that one of the two conflicting hosts may be able to retain its address. 🤞

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 aids timely detection of duplicate addresses. An example illustrating how this helps is given in Section 4. 📣

2.6. Address Usage and Forwarding Rules 🗺️

A host implementing this specification has additional rules to conform to, whether or not it has an interface configured with an IPv4 Link-Local address. 🎀

2.6.1. Source Address Usage 🎯

Since each interface on a host may have an IPv4 Link-Local address in addition to zero or more other addresses configured by other means (e.g., manually or via a DHCP server), a host may have to make a choice about what source address to use when it sends a packet or initiates a TCP connection. Decisions, decisions. 💅

Where both an IPv4 Link-Local and a routable address are available on the same interface, the routable address should be preferred as the source address for new communications, but packets sent from or to the IPv4 Link-Local address are still delivered as expected. The IPv4 Link-Local address may continue to be used as a source address in communications where switching to a preferred address would cause communications failure because of the requirements of an upper-layer protocol (e.g., an existing TCP connection). For more details, see Section 1.7. 🦋

A multi-homed host needs to select an outgoing interface whether or not the destination is an IPv4 Link-Local address. Details of that process are beyond the scope of this specification. After selecting an interface, the multi-homed host should send packets involving IPv4 Link-Local addresses as specified in this document, as if the selected interface were the host's only interface. See Section 3 for further discussion of multi-homed hosts. 🧚

2.6.2. Forwarding Rules 🚦

Whichever interface is used, if the destination address is in the 169.254/16 prefix (excluding the address 169.254.255.255, which is the broadcast address for the Link-Local prefix), then the sender MUST ARP for the destination address and then send its packet directly to the destination on the same physical link. This MUST be done whether the interface is configured with a Link-Local or a routable IPv4 address. 📦

In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. This approach will not work for routers or multi-homed hosts. Refer to section 3 for more discussion of multi-homed hosts. 🍓

The host MUST NOT send a packet with an IPv4 Link-Local destination address to any router for forwarding. 🙅‍♀️

If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable IPv4 source address, if it can. If for any reason the host chooses to send the packet with an IPv4 Link-Local source address (e.g., no routable address is available on the selected interface), then it MUST ARP for the destination address and then send its packet, with an IPv4 Link-Local source address and a routable destination IPv4 address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. 🫶

In the case of a device with a single interface and only a Link-Local IPv4 address, this requirement can be paraphrased as "ARP for everything". Iconic. 😭

In many network stacks, achieving this "ARP for everything" behavior may be as simple as having no primary IP router configured, having the primary IP router address configured to 0.0.0.0, or having the primary IP router address set to be the same as the host's own Link-Local IPv4 address. For suggested behavior in multi-homed hosts, see Section 3. ✨

2.7. Link-Local Packets Are Not Forwarded 🚫

A sensible default for applications which are sending from an IPv4 Link-Local address is to explicitly set the IPv4 TTL to 1. This is not appropriate in all cases, as some applications may require that the IPv4 TTL be set to other values. 🔢

An IPv4 packet whose source and/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 in the IPv4 header. Similarly, a router or other host MUST NOT indiscriminately answer all ARP Requests for addresses in the 169.254/16 prefix. A router may of course answer ARP Requests for one or more IPv4 Link-Local address(es) that it has legitimately claimed for its own use according to the claim-and-defend protocol described in this document. 🧱

This restriction also applies to multicast packets. IPv4 packets with a Link-Local source address MUST NOT be forwarded outside the local link even if they have a multicast destination address. Stay local, it's giving homebody. 🏡

2.8. Link-Local Packets are Local 🏠

The non-forwarding rule means that hosts may assume that all 169.254/16 destination addresses are "on-link" and directly reachable. The 169.254/16 address prefix MUST NOT be subnetted. This specification utilizes ARP-based address conflict detection, which functions by broadcasting on the local subnet. Since such broadcasts are not forwarded, were subnetting to be allowed then address conflicts could remain undetected. 🧠

This does not mean that Link-Local devices are forbidden from any communication outside the local link. IP hosts that implement both Link-Local and conventional routable IPv4 addresses may still use their routable addresses without restriction, as they do today. 🌈

2.9. Higher-Layer Protocol Considerations 🍰

Similar considerations apply at layers above IP. Same energy, different floor. 🪜

For example, designers of Web pages (including automatically generated web pages) SHOULD NOT contain links with embedded IPv4 Link-Local addresses if those pages are viewable from hosts outside the local link where the addresses are valid. Nobody wants a dead link in their feed. 🙈

As IPv4 Link-Local addresses may change at any time and have limited scope, IPv4 Link-Local addresses MUST NOT be stored in the DNS. Not the DNS, not ever. 🚫🌐

2.10. Privacy Concerns 🕵️

Another reason to restrict leakage of IPv4 Link-Local addresses outside the local link is privacy concerns. If IPv4 Link-Local addresses are derived from a hash of the MAC address, some argue that they could be indirectly associated with an individual, and thereby used to track that individual's activities. Within the local link the hardware addresses in the packets are all directly observable, so as long as IPv4 Link-Local addresses don't leave the local link, they provide no more information to an intruder than could be gained by direct observation of hardware addresses. Protect your side-quest energy. 🫣

2.11. Interaction between DHCPv4 client and IPv4 Link-Local State Machines 🔄

As documented in Appendix A, early implementations of IPv4 Link-Local have modified the DHCP state machine. Field experience shows that these modifications reduce the reliability of the DHCP service. Oops, not the move. 😬

A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular, configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts, or to change the behavior of the DHCP state machine in any other way. Leave the DHCP client alone, it's doing its best. 🎀

Further discussion of this issue is provided in "Detection of Network Attachment (DNA) in IPv4" [DNAv4]. 📚

3. Considerations for Multiple Interfaces ✨

okay so this part is all about what happens when a host has more than one address, whether or not it has more than one physical interface 🫶 other examples are different logical endpoints like tunnels or VPNs, and multiple logical networks sitting on the same physical medium. people call this "multi-homing" and it's giving a lot of chaos 💀

hosts with more than one active interface that also choose to do dynamic configuration of IPv4 Link-Local addresses on one or more of those interfaces are gonna run into various problems 😭 this section just lists those problems and only kinda hints at how you might fix them. ngl there is no silver bullet yet that solves all of these in every case, in a general way 🙈 implementors have to think these issues through before they put this protocol on a system that might have multiple active interfaces as part of a TCP/IP stack that can do multi-homing. no shortcuts, bestie 💅

3.1. Scoped Addresses 🦋

a host can be attached to more than one network at the same time. it would be so nice if there was one single address space used in every network, but literally that is not the case 😩 addresses used in one network, whether that's a network behind a NAT or a link where IPv4 Link-Local addresses are used, can't be used in another network and don't do the same thing there.

it would also be nice if addresses weren't exposed to applications, but they totally are 🙃 most TCP/IP software waiting for messages receives them from any interface at a particular port number for a particular transport protocol. applications are usually only aware (and only care) that they got a message. the application knows the sender's address, which is where it'll reply 💌

the first scoped address problem is source address selection 🔥 a multi-homed host has more than one address, so which one should be used as the source when sending to a particular destination? this is usually answered by looking at a routing table, which says which interface (with which address) to send from, and how to send, like whether to forward to a router or send directly. it gets messy because the address range the destination lives in might be ambiguous, so the table may not be able to give a good answer 🌀 this problem is tangled up with next-hop selection, which is talked about in Section 3.2.

the second scoped address problem comes from scoped parameters leaking outside their scope 🚨 that one is discussed in Section 7.

it is possible to overcome these problems ✨ one way is to expose scope information to applications so they're always aware of what scope a peer is in. then the correct interface could be picked, and a safe procedure could be followed with respect to forwarding addresses and other scoped parameters 👑 there are other possible approaches too. none of these methods have been standardized for IPv4, and none are specified in this document. a good API design could help a lot, either by exposing address scopes to "scoped-address aware" applications, or by cleverly wrapping the scoping info and logic so apps do the right thing without even knowing about address scoping 🧚

an implementer could take on solving these problems, but they can't just ignore them 😤 with enough experience, the hope is that specifications will show up explaining how to get past scoped address multi-homing problems 🌈

3.2. Address Ambiguity 🌸

this is the core problem with IPv4 Link-Local destination addresses being reachable on more than one interface. what should a host do when it needs to send to Link-Local destination L and L can be resolved using ARP on more than one link? 😵‍💫

even if a Link-Local address can only be resolved on one link at a given moment, there's no guarantee it stays unambiguous in the future 🙈 additional hosts on other interfaces might claim the address L too.

one possibility is to support this only when the application specifically says which interface to send from 💖

there is no standard or obvious solution to this problem 💀 existing application software written for the IPv4 protocol suite is mostly incapable of dealing with address ambiguity. this doesn't stop an implementer from finding a solution, writing applications that can use it, and providing a host that can support dynamic configuration of IPv4 Link-Local addresses on more than one interface. it's just that this solution will almost surely not be broadly applicable to existing software, or transparent to higher layers 😭

given that the IP stack must have the outbound interface associated with a packet that needs to go to a Link-Local destination address, interface selection has to happen 🔍 the outbound interface can't be derived from the packet's header parameters, like source or destination address (for example, by using a forwarding table lookup). so outbound interface association has to be done explicitly through other means. this specification doesn't stipulate what those means are 🤷‍♀️

3.3. Interaction with Hosts with Routable Addresses 🎀

this spec pays attention to the transition from using IPv4 Link-Local addresses to routable addresses (see Section 1.5) 🦋 the goal is to let a host with a single interface first support Link-Local configuration, then gracefully move over to using a routable address. since a host transitioning to a routable address might temporarily have more than one address active, the scoped address issues from Section 3.1 will apply 🌀

when a host acquires a routable address, it doesn't need to keep its Link-Local address just to talk to other devices on the link that are only using Link-Local addresses 🙌 any host conforming to this spec knows that, no matter the source address, an IPv4 Link-Local destination has to be reached by forwarding directly to the destination, not via a router. so that host doesn't need a Link-Local source address in order to send to a Link-Local destination address. main character energy 👑

a host with an IPv4 Link-Local address may send to a destination that does not have an IPv4 Link-Local address 🫠 if the host isn't multi-homed, it's simple and unambiguous: using ARP and forwarding directly to on-link destinations is the default route. if the host is multi-homed, though, the routing policy gets way more complicated, especially if one of the interfaces has a routable address and the default route is (sensibly) pointed at a router reachable through that interface 😩 the example below shows this problem and gives a common solution for it.

                     i1 +---------+ i2   i3 +-------+
           ROUTER-------=  HOST1  =---------= HOST2 |
                  link1 +---------+  link2  +-------+

in the figure above, HOST1 is connected to link1 and link2 🔗 interface i1 has a routable address, while i2 has an IPv4 Link-Local address. HOST1 has its default route set to ROUTER's address, through i1. HOST1 will route to destinations in 169.254/16 via i2, sending directly to the destination 💅

HOST2 has a configured (non-Link-Local) IPv4 address assigned to i3 🧁

using a name resolution or service discovery protocol, HOST1 can discover HOST2's address 🔎 since HOST2's address is not in 169.254/16, HOST1's routing policy will send datagrams to HOST2 via i1, to the ROUTER. unless there's a route from ROUTER to HOST2, the datagrams sent from HOST1 to HOST2 won't reach it 😭

one solution is for a host to try reaching any host locally (using ARP) for which it gets an unreachable ICMP error message (ICMP message codes 0, 1, 6 or 7 [RFC792]) 🫶 the host tries all its attached links in a round robin fashion. this has been implemented successfully for some IPv6 hosts, to get around exactly this problem 🌈 in terms of this example, HOST1, after failing to reach HOST2 via the ROUTER, will attempt to forward to HOST2 via i2 and succeed ✨

it may also be possible to overcome this problem using the techniques described in section 3.2, or other means not discussed here 🧚 this specification doesn't provide a standard solution, and it doesn't stop implementers from supporting multi-homed configurations, as long as they address the concerns in this section for the applications that will be supported on the host 💜

3.4. Unintentional Autoimmune Response 💀

⚠️ careful, bestie: if a multi-homed host can support more than one interface on the same link, and all of them support IPv4 Link-Local autoconfiguration, things can get really weird 🙈

if those interfaces try to allocate the same address, they'll defend the host against itself, and that makes the claiming algorithm fail 😱 literal self-sabotage, iconic 💀 the simplest fix is to run the algorithm independently on each interface configured with IPv4 Link-Local addresses 🔧

specifically, ARP packets that look like they're claiming an address assigned to a specific interface only count as a conflict if they're received on that interface and their hardware address belongs to some other interface 🔍

if a host has two interfaces on the same link, claiming and defending on those interfaces has to make sure they end up with different addresses, just like they would if they were on different hosts 👯‍♀️ also, some of the ways a host can end up with two interfaces on the same link are unexpected and non-obvious 😭 like when a host has Ethernet and 802.11 wireless, but those two links are bridged together (possibly even without the host's user knowing) 🌸

4. Healing of Network Partitions 🩹✨

okay so hosts on totally separate network links can end up picking the SAME IPv4 Link-Local address 😭. If those links get joined or bridged later, you could have two hosts on one link trying to use the same address. Whenever either host tries to talk to another host on the network, it'll eventually broadcast an ARP packet, and that's how they catch the conflict 👀.

When the conflict gets detected, the forced reconfiguration can be disruptive and TCP connections might break 💔. BUT it's expected to be rare! It should be pretty uncommon for networks to get joined while the hosts on them are active. Also, 65024 addresses are available for IPv4 Link-Local use, so even when two small networks are joined, the chance of a conflict for any given host is pretty small 🌸.

Joining two large networks (ones with a substantial number of hosts per segment) has a bigger chance of conflict 😬. Once previously separated segments join, one or more hosts will probably need a new IPv4 Link-Local address, and TCP connections get lost along the way. If separation and rejoining happen a lot, like in remotely bridged networks, that could get really disruptive. Still, unless the number of hosts on the joined segments is very large, the traffic from the join and the conflict resolution will be small 🫶.

Sending ARP replies that have IPv4 Link-Local sender addresses via broadcast instead of unicast means conflicts get detected as soon as they become potential problems, but no sooner ✨. Picture this: hosts A and B both configured the same Link-Local address, X, and then their links get joined. They can just sit there in that state until A, B, or some other host tries to start communicating. If some other host C sends an ARP request for address X, and A and B both reply with normal unicast ARP replies, then C might get confused. But A and B still wouldn't know there's a problem, because neither one would have seen the other's packet 🙈. Broadcasting those replies lets A and B see each other's conflicting ARP packets and respond accordingly 💅.

Sending periodic gratuitous ARPs to catch these conflicts sooner is NOT necessary, wastes network bandwidth, and might even be detrimental 💀. For example, if the links were only joined briefly and separated again before A or B started any new communication, the temporary conflict would have been benign, and no forced reconfiguration would have been needed. Triggering an unnecessary reconfiguration in that case wouldn't serve any useful purpose. Hosts SHOULD NOT send periodic gratuitous ARPs 🚫.

5. Security Considerations 🔐

The use of IPv4 Link-Local Addresses may open a network host up to new attacks 😨. A host that didn't have an IP address and had no IP stack running wasn't susceptible to IP-based attacks. But once it configures a working address, it may now be vulnerable to IP-based attacks.

The ARP protocol [RFC826] is insecure 💀. A malicious host can send fraudulent ARP packets on the network and mess with other hosts. For example, it's easy for a host to answer every ARP request with a reply giving its own hardware address, which basically claims ownership of every address on the network 🙃.

NOTE: There are certain kinds of local links, like wireless LANs, that provide no physical security 📡. Because of that, it would be very unwise for an implementer to assume that when a device is only communicating on the local link, it can skip normal security precautions. Failing to implement appropriate security measures could expose users to considerable risks ⚠️.

A host implementing IPv4 Link-Local configuration has an extra vulnerability to selective reconfiguration and disruption 😤. An on-link attacker can send ARP packets that make a host break all its connections by switching to a new address. The attacker could force the host to select certain addresses, or stop it from ever finishing address selection. This is a separate threat from the spoofed ARPs described in the paragraph before this one.

Implementations and users should also note that a node that gives up an address and reconfigures, as required by section 2.5, allows the possibility that another node can easily and successfully hijack existing TCP connections 🏴‍☠️.

Implementers are advised that the Internet Protocol architecture expects every networked device or host to implement security that's adequate to protect the resources it can access, including the network itself, against known or credible threats 🛡️. Even though using IPv4 Link-Local addresses may reduce the number of threats a device is exposed to, implementers of devices supporting the Internet Protocol must not assume that a customer's local network is free from security risks.

There may be particular kinds of devices, or particular environments, where the security provided by the network is adequate to protect the resources the device can access 🤷‍♀️. Still, it would be misleading to make a general statement that the requirement to provide security is reduced for devices using IPv4 Link-Local addresses as their sole means of access.

In all cases, whether or not IPv4 Link-Local addresses are used, implementers of devices supporting the Internet Protocol need to analyze the known and credible threats a specific host or device might face. To the extent that it's feasible, they should provide security mechanisms that ameliorate or reduce the risks associated with those threats 🫡.

6. Application Programming Considerations 🧑‍💻

Using IPv4 Link-Local autoconfigured addresses adds extra challenges for application writers 😩, and it may cause existing application software to fail.

6.1. Address Changes, Failure and Recovery

IPv4 Link-Local addresses used by an application can change over time 🔄. Some application software will fail when it hits an address change. For example, existing client TCP connections get aborted, servers whose addresses change have to be rediscovered, blocked reads and writes exit with an error condition, and so on 💔.

Vendors producing application software that will be used on IP implementations supporting IPv4 Link-Local address configuration SHOULD detect and cope with address change events 🛠️. Vendors producing IPv4 implementations that support IPv4 Link-Local address configuration SHOULD expose address change events to applications 📣.

6.2. Limited Forwarding of Locators

IPv4 Link-Local addresses MUST NOT be forwarded via an application protocol (for example, in a URL) to a destination that is not on the same link 🚧. This is discussed further in Sections 2.9 and 3.

Existing distributed application software that forwards address information may fail 😵. For example, FTP [RFC959] (when not using passive mode) transmits the IP address of the client. Say a client starts up and gets its IPv4 configuration while it only has a Link-Local address. Later, the host gets a global IP address, and the client contacts an FTP server outside the local link. If the FTP client sends its old Link-Local address instead of its new global IP address in the FTP "port" command, the FTP server can't open a data connection back to the client, and the FTP operation fails 😭.

6.3. Address Ambiguity

Application software running on a multi-homed host that supports IPv4 Link-Local address configuration on more than one interface may fail 🌀.

This happens because application software assumes an IPv4 address is unambiguous, meaning it can refer to only one host. IPv4 Link-Local addresses are only unique on a single link. A host attached to multiple links can easily end up with the same address on more than one interface, or first on one interface and later on another. In any case, that address ends up associated with more than one host. Most existing software isn't ready for this ambiguity 🙃. In the future, application programming interfaces could be developed to prevent this problem. This issue is discussed in Section 3.

7. Router Considerations 🧭

A router MUST NOT forward a packet with an IPv4 Link-Local source or destination address, no matter how the router's default route is configured or which routes it got from dynamic routing protocols 🚫.

A router that receives a packet with an IPv4 Link-Local source or destination address MUST NOT forward the packet. This stops packets from getting sent back onto the network segment they came from, or onto any other segment 🛑.

8. IANA Considerations 📋

The IANA has allocated the prefix 169.254/16 for the use described in this document 🎀. The first and last 256 addresses in this range (169.254.0.x and 169.254.255.x) are allocated by Standards Action, as defined in "Guidelines for Writing an IANA" (BCP 26) [RFC2434]. No other IANA services are required by this document.

9. Constants 🔢

The following timing constants are used in this protocol. They are not meant to be user configurable 🙅‍♀️.

PROBE_WAIT           1 second   (initial random delay)
PROBE_NUM            3          (number of probe packets)
PROBE_MIN            1 second   (minimum delay till repeated probe)
PROBE_MAX            2 seconds  (maximum delay till repeated probe)
ANNOUNCE_WAIT        2 seconds  (delay before announcing)
ANNOUNCE_NUM         2          (number of announcement packets)
ANNOUNCE_INTERVAL    2 seconds  (time between announcement packets)
MAX_CONFLICTS       10          (max conflicts before rate limiting)
RATE_LIMIT_INTERVAL 60 seconds  (delay between successive attempts)
DEFEND_INTERVAL     10 seconds  (minimum interval between defensive
                                 ARPs).

10. References 📚

10.1. Normative References

[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. 🧾

[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. 🧾

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🧾

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 🧾

10.2. Informative References ✨

Okay so these are the background reads 📚 The spec points to them for context, but they aren't the rules themselves.

[802]     IEEE Standards for Local and Metropolitan Area Networks:
             Overview and Architecture, ANSI/IEEE Std 802, 1990.

[802.3]   ISO/IEC 8802-3 Information technology - Telecommunications
             and information exchange between systems - Local and
             metropolitan area networks - Common specifications - Part
             3:  Carrier Sense Multiple Access with Collision Detection
             (CSMA/CD) Access Method and Physical Layer Specifications,
             (also ANSI/IEEE Std 802.3- 1996), 1996.

[802.5]   ISO/IEC 8802-5 Information technology - Telecommunications
             and information exchange between systems - Local and
             metropolitan area networks - Common specifications - Part
             5: Token ring access method and physical layer
             specifications, (also ANSI/IEEE Std 802.5-1998), 1998.

[802.11]  Information technology - Telecommunications and information
             exchange between systems - Local and metropolitan area
             networks - Specific Requirements Part 11:  Wireless LAN
             Medium Access Control (MAC) and Physical Layer (PHY)
             Specifications, IEEE Std. 802.11-1999, 1999.

[RFC959]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD
             9, RFC 959, October 1985.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
             and E. Lear, "Address Allocation for Private Internets",
             BCP 5, RFC 1918, February 1996.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
             March 1997.

[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
             Autoconfiguration", RFC 2462, December 1998.

[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with
             the IP Network Address Translator", RFC 3027, January 2001.

[DNAv4]   Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
             Work in Progress, July 2004.

[LLMNR]   Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast
             Name Resolution (LLMNR)", Work in Progress, June 2004.

Acknowledgments 🫶

Huge thank yous 💜 to (in alphabetical order) Jim Busse, Pavani Diwanji, Donald Eastlake 3rd, Robert Elz, Peter Ford, Spencer Giacalone, Josh Graessley, Brad Hards, Myron Hattig, Hugh Holbrook, Christian Huitema, Richard Johnson, Kim Yong-Woon, Mika Liljeberg, Rod Lopez, Keith Moore, Satish Mundra, Thomas Narten, Erik Nordmark, Philip Nye, Howard Ridenour, Daniel Senie, Dieter Siegmund, Valery Smyslov, and Ryan Troll for their contributions. Literally the whole squad 👑

Appendix A - Prior Implementations 🦋

A.1. Apple Mac OS 8.x and 9.x.

Mac OS picks its IP address on a pseudo-random basis 🎲 The selected address gets saved in persistent storage so it can keep being used after a reboot, when possible.

Mac OS sends nine DHCPDISCOVER packets, with an interval of two seconds between packets. If no response is received from any of these requests (18 seconds), it will autoconfigure.

Upon finding that a selected address is in use, Mac OS will select a new random address and try again, at a rate limited to no more than one attempt every two seconds.

Autoconfigured Mac OS systems check for the presence of a DHCP server every five minutes. If a DHCP server is found but Mac OS is not successful in obtaining a new lease, it keeps the existing autoconfigured IP address. If Mac OS is successful at obtaining a new lease, it drops all existing connections without warning. This may cause users to lose sessions in progress 😭 Once a new lease is obtained, Mac OS will not allocate further connections using the autoconfigured IP address.

Mac OS systems do not send packets addressed to a Link-Local address to the default gateway if one is present; these addresses are always resolved on the local segment.

Mac OS systems by default send all outgoing unicast packets with a TTL of 255. All multicast and broadcast packets are also sent with a TTL of 255 if they have a source address in the 169.254/16 prefix.

Mac OS implements media sense where the hardware (and driver software) supports this. As soon as network connectivity is detected, a DHCPDISCOVER will be sent on the interface. This means that systems will immediately transition out of autoconfigured mode as soon as connectivity is restored 🔥

A.2. Apple Mac OS X Version 10.2

Mac OS X also picks the IP address on a pseudo-random basis 🎲 The selected address is saved in memory so it can be re-used during subsequent autoconfiguration attempts during a single boot of the system.

Autoconfiguration of a Link-Local address depends on the results of the DHCP process. DHCP sends two packets, with timeouts of one and two seconds. If no response is received (three seconds), it begins autoconfiguration. DHCP continues sending packets in parallel for a total time of 60 seconds.

At the start of autoconfiguration, it generates 10 unique random IP addresses, and probes each one in turn for 2 seconds. It stops probing after finding an address that is not in use, or the list of addresses is exhausted.

If DHCP is not successful, it waits five minutes before starting over again. Once DHCP is successful, the autoconfigured Link-Local address is given up. The Link-Local subnet, however, remains configured.

Autoconfiguration is only attempted on a single interface at any given moment in time.

Mac OS X ensures that the connected interface with the highest priority is associated with the Link-Local subnet. Packets addressed to a Link-Local address are never sent to the default gateway, if one is present. Link-local addresses are always resolved on the local segment.

Mac OS X implements media sense where the hardware and driver support it. When the network media indicates that it has been connected, the autoconfiguration process begins again, and attempts to re-use the previously assigned Link-Local address. When the network media indicates that it has been disconnected, the system waits four seconds before de-configuring the Link-Local address and subnet. If the connection is restored before that time, the autoconfiguration process begins again. If the connection is not restored before that time, the system chooses another interface to autoconfigure.

Mac OS X by default sends all outgoing unicast packets with a TTL of 255. All multicast and broadcast packets are also sent with a TTL of 255 if they have a source address in the 169.254/16 prefix.

A.3. Microsoft Windows 98/98SE

Windows 98/98SE systems choose their IPv4 Link-Local address on a pseudo-random basis. The address selection algorithm is based on computing a hash on the interface's MAC address, so that a large collection of hosts should obey the uniform probability distribution in choosing addresses within the 169.254/16 address space. Deriving the initial IPv4 Link-Local address from the interface's MAC address also ensures that systems rebooting will obtain the same autoconfigured address, unless a conflict is detected 🧚

When in INIT state, the Windows 98/98SE DHCP Client sends out a total of 4 DHCPDISCOVERs, with an inter-packet interval of 6 seconds. When no response is received after all 4 packets (24 seconds), it will autoconfigure an address.

The autoconfigure retry count for Windows 98/98SE systems is 10. After trying 10 autoconfigured IPv4 addresses, and finding all are taken, the host will boot without an IPv4 address.

Autoconfigured Windows 98/98SE systems check for the presence of a DHCP server every five minutes. If a DHCP server is found but Windows 98 is not successful in obtaining a new lease, it keeps the existing autoconfigured IPv4 Link-Local address. If Windows 98/98SE is successful at obtaining a new lease, it drops all existing connections without warning. This may cause users to lose sessions in progress. Once a new lease is obtained, Windows 98/98SE will not allocate further connections using the autoconfigured IPv4 Link-Local address.

Windows 98/98SE systems with an IPv4 Link-Local address do not send packets addressed to an IPv4 Link-Local address to the default gateway if one is present; these addresses are always resolved on the local segment.

Windows 98/98SE systems by default send all outgoing unicast packets with a TTL of 128. TTL configuration is performed by setting the Windows Registry Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\Parameters\DefaultTTL of type REG_DWORD to the appropriate value. However, this default TTL will apply to all packets. While this facility could be used to set the default TTL to 255, it cannot be used to set the default TTL of IPv4 Link-Local packets to one (1), while allowing other packets to be sent with a TTL larger than one.

Windows 98/98SE systems do not implement media sense. This means that network connectivity issues (such as a loose cable) may prevent a system from contacting the DHCP server, thereby causing it to auto-configure. When the connectivity problem is fixed (such as when the cable is re-connected) the situation will not immediately correct itself. Since the system will not sense the re-connection, it will remain in autoconfigured mode until an attempt is made to reach the DHCP server. 🙈

The DHCP server included with Windows 98SE Internet Connection Sharing (ICS) (a NAT implementation) allocates out of the 192.168/16 private address space by default.

However, it is possible to change the allocation prefix via a registry key, and no checks are made to prevent allocation out of the IPv4 Link-Local prefix. When configured to do so, Windows 98SE ICS will rewrite packets from the IPv4 Link-Local prefix and forward them beyond the local link. Windows 98SE ICS does not automatically route for the IPv4 Link-Local prefix, so that hosts obtaining addresses via DHCP cannot communicate with autoconfigured-only devices.

Other home gateways exist that allocate addresses out of the IPv4 Link-Local prefix by default. Windows 98/98SE systems can use a 169.254/16 IPv4 Link-Local address as the source address when communicating with non-Link-Local hosts. Windows 98/98SE does not support router solicitation/advertisement. Windows 98/98SE systems will not automatically discover a default gateway when in autoconfigured mode.

A.4. Windows XP, 2000, and ME

The autoconfiguration behavior of Windows XP, Windows 2000, and Windows ME systems is identical to Windows 98/98SE except in the following respects:

Media Sense
Router Discovery
Silent RIP

Windows XP, 2000, and ME implement media sense. As soon as network connectivity is detected, a DHCPREQUEST or DHCPDISCOVER will be sent on the interface. This means that systems will immediately transition out of autoconfigured mode as soon as connectivity is restored ⭐

Windows XP, 2000, and ME also support router discovery, although it is turned off by default. Windows XP and 2000 also support a RIP listener. This means that they may inadvertently discover a default gateway while in autoconfigured mode.

ICS on Windows XP/2000/ME behaves identically to Windows 98SE with respect to address allocation and NATing of Link-Local prefixes. 🌈

Authors' Addresses ✨

Okay bestie, here are the people who wrote this 🎀 Cheshire, Aboba, and Guttman, and how to reach each of them 💌

Stuart Cheshire
Apple Computer, Inc.
1 Infinite Loop
Cupertino
California 95014, USA

Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 425 818 4011
EMail: bernarda@microsoft.com

Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt Germany

Phone: +49 7263 911 701
EMail: erik@spybeam.org

Full Copyright Statement 💖

The copyright here belongs to The Internet Society, and it's dated 2005 🦋 Copyright (C) The Internet Society (2005). This document is still under BCP 78, so the authors keep all their rights, except for whatever BCP 78 says otherwise 📜

The document and everything in it is handed over "AS IS" 🫶 That means the contributor, the organization they represent or sponsor (if there is one), The Internet Society, and the Internet Engineering Task Force all say NO to warranties. That covers express or implied ones, including no promise that using the info won't infringe anybody's rights, and no implied warranty of merchantability or fitness for a particular purpose. Dramatic? Yes. Necessary? Also yes 💀

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

Okay, so the IETF is not picking a side on whether any patents or other IP rights cover the tech in this doc 🙅‍♀️ It also doesn't say whether anyone can get a license for them, and it hasn't gone looking for any either. If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat live in the IETF's online IPR repository, along with any promised licenses. You can also find the results of anyone trying to get a general license or permission for implementers or users of this spec. The link is http://www.ietf.org/ipr 🔗

The IETF is also inviting anyone to say something if they know about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 🫶 Send that info to ietf-ipr@ietf.org 💌

Acknowledgement 🌸

Big thank-you energy here 💜 The RFC Editor function is currently funded by The Internet Society 🙌

That's the whole thing, bestie! 🌈✨ Every RFC needs a team that keeps the lights on, and this one has one 💖

📦 where this page comes from

ietf: rfc3927 2005-05
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms