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 MUST NOT be selected by a host
using this dynamic configuration mechanism.
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 is different for each
host, such as its IEEE 802 MAC address, then the pseudo-random number
generator SHOULD be seeded using a value derived from this
information. This means that even without using any other persistent
storage, a host will usually select the same IPv4 Link-Local address
each time it is booted, which can be convenient for debugging and
other operational reasons. Seeding the pseudo-random number
generator using the real-time clock or any other information which is
(or may be) identical in every host is NOT suitable for this purpose,
because a group of hosts that are all powered on at the same time
might then all generate the same sequence, resulting in a never-
ending series of conflicts as the hosts move in lock-step through
exactly the same pseudo-random sequence, conflicting on every address
they probe.
Hosts that are equipped with persistent storage MAY, for each
interface, record the IPv4 address they have selected. On booting,
hosts with a previously recorded address SHOULD use that address as
their first candidate when probing. This increases the stability of
addresses. For example, if a group of hosts are powered off at
night, then when they are powered on the next morning they will all
resume using the same addresses, instead of picking different
addresses and potentially having to resolve conflicts that arise.
2.2. Claiming a Link-Local Address
After it has selected an IPv4 Link-Local address, a host MUST test to
see if the IPv4 Link-Local address is already in use before beginning
to use it. When a network interface transitions from an inactive to
an active state, the host does not have knowledge of what IPv4 Link-
Local addresses may currently be in use on that link, since the point
of attachment may have changed or the network interface may have been
inactive when a conflicting address was claimed.
Were the host to immediately begin using an IPv4 Link-Local address
which is already in use by another host, this would be disruptive to
that other host. Since it is possible that the host has changed its
point of attachment, a routable address may be obtainable on the new
network, and therefore it cannot be assumed that an IPv4 Link-Local
address is to be preferred.
Before using the IPv4 Link-Local address (e.g., using it 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 to
achieve better confidence that using the IPv4 Link-Local address will
not cause disruption.
Examples of events that involve an interface becoming active include:
Reboot/startup
Wake from sleep (if network interface was inactive during sleep)
Bringing up 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. This would be a waste of network bandwidth, and is
unnecessary due to the ability of hosts to 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
do not support ARP other techniques may be available for determining
whether a particular IPv4 address is currently in use. However, the
application of claim-and-defend mechanisms to such 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 through which it is sending the packet. The
’sender IP address’ field MUST be set to all zeroes, to avoid
polluting ARP caches in other hosts on the same link in the case
where the address turns out to be already 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 constructed this way with an all-zero
’sender IP address’ is referred to as an "ARP Probe".
When ready to begin probing, the host should then wait for a random
time interval selected uniformly in the range zero to PROBE_WAIT
seconds, and should then send PROBE_NUM probe packets, each of these
probe packets spaced randomly, PROBE_MIN to PROBE_MAX seconds apart.
If during this period, from the beginning 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
where the probe is being performed where the packet’s ’sender IP
address’ is the address being probed for, then the host MUST treat
this address as being in use by some other host, and MUST select a
new pseudo-random address and repeat the process. In addition, 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 attempting to configure, then the host MUST
similarly treat this as an address conflict and select a new address
as above. This can occur if two (or more) hosts attempt to configure
the same IPv4 Link-Local address at the same time.
A host should maintain a counter of the number of address conflicts
it has experienced in the process of trying to acquire an address,
and if the number of conflicts exceeds MAX_CONFLICTS then the host
MUST limit the rate at which it probes for new addresses to no more
than one new address per RATE_LIMIT_INTERVAL. This is to prevent
catastrophic ARP storms in pathological failure cases, such as a
rogue host that answers all ARP probes, causing legitimate hosts to
go into an infinite loop attempting to select a usable address.
If, by ANNOUNCE_WAIT seconds after the transmission of the last ARP
Probe 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
Network technologies may emerge for which shorter delays are
appropriate than those required by this document. A subsequent IETF
publication may be produced providing guidelines for different values
for PROBE_WAIT, PROBE_NUM, PROBE_MIN and PROBE_MAX on those
technologies.
2.4. Announcing an Address
Having probed to determine a unique address to use, the host MUST
then announce its claimed address by broadcasting ANNOUNCE_NUM ARP
announcements, spaced ANNOUNCE_INTERVAL seconds apart. An ARP
announcement is identical to the ARP Probe described above, except
that now the sender and target IP addresses are both set to the
host’s newly selected IPv4 address. The purpose of these ARP
announcements is to make sure that other hosts on the link do not
have stale ARP cache entries left over from some other host that may
previously have been using the same address.
2.5. Conflict Detection and Defense
Address conflict detection is not limited to the address selection
phase, when a host is sending ARP probes. Address conflict detection
is an ongoing process that is in effect for as long as a host is
using an IPv4 Link-Local address. At any time, if a host receives an
ARP packet (request *or* reply) on an interface where the ’sender IP
address’ is the IP address the host has configured for that
interface, but the ’sender hardware address’ does not match the
hardware address of that interface, then this is a conflicting ARP
packet, indicating an address conflict.
A host MUST respond to a conflicting ARP packet as described 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.
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.
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 an Link-
Local IPv4 address, this requirement can be paraphrased as "ARP for
everything".
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.
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.
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.
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.
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.
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.
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.
Further discussion of this issue is provided in "Detection of Network
Attachment (DNA) in IPv4" [DNAv4].
3. Considerations for Multiple Interfaces
The considerations outlined here also apply whenever a host has
multiple IP addresses, whether or not it has multiple physical
interfaces. Other examples of multiple interfaces include different
logical endpoints (tunnels, virtual private networks etc.) and
multiple logical networks on the same physical medium. This is often
referred to as "multi-homing".
Hosts which have more than one active interface and elect to
implement dynamic configuration of IPv4 Link-Local addresses on one
or more of those interfaces will face various problems. This section
lists these problems but does no more than indicate how one might
solve them. At the time of this writing, there is no silver bullet
which solves these problems in all cases, in a general way.
Implementors must think through these issues before implementing the
protocol specified in this document on a system which may have more
than one active interface as part of a TCP/IP stack capable of
multi-homing.
3.1. Scoped Addresses
A host may be attached to more than one network at the same time. It
would be nice if there was a single address space used in every
network, but this is not the case. Addresses used in one network, be
it a network behind a NAT or a link on which IPv4 Link-Local
addresses are used, cannot be used in another network and have the
same effect.
It would also be nice if addresses were not exposed to applications,
but they are. Most software using TCP/IP which await messages
receives from any interface at a particular port number, for a
particular transport protocol. Applications are generally only aware
(and care) that they have received a message. The application knows
the address of the sender to which the application will reply.
The first scoped address problem is source address selection. A
multi-homed host has more than one address. Which address should be
used as the source address when sending to a particular destination?
This question is usually answered by referring to a routing table,
which expresses on which interface (with which address) to send, and
how to send (should one forward to a router, or send directly). The
choice is made complicated by scoped addresses because the address
range in which the destination lies may be ambiguous. The table may
not be able to yield a good answer. This problem is bound up with
next-hop selection, which is discussed in Section 3.2.
The second scoped address problem arises from scoped parameters
leaking outside their scope. This is discussed in Section 7.
It is possible to overcome these problems. One way is to expose
scope information to applications such that they are always aware of
what scope a peer is in. This way, the correct interface could be
selected, and a safe procedure could be followed with respect to
forwarding addresses and other scoped parameters. There are other
possible approaches. None of these methods have been standardized
for IPv4 nor are they specified in this document. A good API design
could mitigate the problems, either by exposing address scopes to
’scoped-address aware’ applications or by cleverly encapsulating the
scoping information and logic so that applications do the right thing
without being aware of address scoping.
An implementer could undertake to solve these problems, but cannot
simply ignore them. With sufficient experience, it is hoped that
specifications will emerge explaining how to overcome scoped address
multi-homing problems.
3.2. Address Ambiguity
This is a core problem with respect to 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 be resolved on only one link at a
given moment, there is no guarantee that it will remain unambiguous
in the future. Additional hosts on other interfaces may claim the
address L as well.
One possibility is to support this only in the case where the
application specifically expresses 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 largely
incapable of dealing with address ambiguity. This does not preclude
an implementer from finding a solution, writing applications which
are able to use it, and providing a host which can support dynamic
configuration of IPv4 Link-Local addresses on more than one
interface. This solution will almost surely not be generally
applicable to existing software and transparent to higher layers,
however.
Given that the IP stack must have the outbound interface associated
with a packet that needs to be sent to a Link-Local destination
address, interface selection must occur. The outbound interface
cannot be derived from the packet’s header parameters such as source
or destination address (e.g., by using the forwarding table lookup).
Therefore, outbound interface association must be done explicitly
through other means. The specification does not stipulate those
means.
3.3. Interaction with Hosts with Routable Addresses
Attention is paid in this specification to transition from the use of
IPv4 Link-Local addresses to routable addresses (see Section 1.5).
The intention is to allow a host with a single interface to first
support Link-Local configuration then gracefully transition to the
use of a routable address. Since the host transitioning to the use
of a routable address may temporarily have more than one address
active, the scoped address issues described in Section 3.1 will
apply. When a host acquires a routable address, it does not need to
retain its Link-Local address for the purpose of communicating with
other devices on the link that are themselves using only Link-Local
addresses: any host conforming to this specification knows that
regardless of source address an IPv4 Link-Local destination must be
reached by forwarding directly to the destination, not via a router;