Request for Comments: 3927 Apple Computer
Category: Standards Track B. Aboba
Microsoft Corporation
E. Guttman
Sun Microsystems
March 2005
Dynamic Configuration of IPv4 Link-Local Addresses
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
To participate in wide-area IP networking, a host needs to be
configured with IP addresses for its interfaces, either manually by
the user or automatically from a source on the network such as a
Dynamic Host Configuration Protocol (DHCP) server. Unfortunately,
such address configuration information may not always be available.
It is therefore beneficial for a host to be able to depend on a
useful subset of IP networking functions even when no address
configuration is available. This document describes how a host may
automatically configure an interface with an IPv4 address within the
169.254/16 prefix that is valid for communication with other devices
connected to the same physical (or logical) link.
IPv4 Link-Local addresses are not suitable for communication with
devices not directly connected to the same physical (or logical)
link, and are only used where stable, routable addresses are not
available (such as on ad hoc or isolated networks). This document
does not recommend that IPv4 Link-Local addresses and routable
addresses be configured simultaneously on the same interface.
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. . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . 9
2.2. Claiming a Link-Local Address. . . . . . . . . . . . . 10
2.3. Shorter Timeouts . . . . . . . . . . . . . . . . . . . 12
2.4. Announcing an Address. . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . 16
2.10. Privacy Concerns . . . . . . . . . . . . . . . . . . . 17
2.11. Interaction between DHCPv4 and IPv4 Link-Local
State Machines . . . . . . . . . . . . . . . . . . . . 17
3. Considerations for Multiple Interfaces. . . . . . . . . . . . 17
3.1. Scoped Addresses . . . . . . . . . . . . . . . . . . . 18
3.2. Address Ambiguity. . . . . . . . . . . . . . . . . . . 19
3.3. Interaction with Hosts with Routable Addresses . . . . 19
3.4. Unintentional Autoimmune Response. . . . . . . . . . . 21
4. Healing of Network Partitions . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. Application Programming Considerations. . . . . . . . . . . . 24
6.1. Address Changes, Failure and Recovery. . . . . . . . . 24
6.2. Limited Forwarding of Locators . . . . . . . . . . . . 24
6.3. Address Ambiguity. . . . . . . . . . . . . . . . . . . 24
7. Router Considerations . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . 26
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A - Prior Implementations . . . . . . . . . . . . . . . . 28
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
As the Internet Protocol continues to grow in popularity, it becomes
increasingly valuable to be able to use familiar IP tools such as FTP
not only for global communication, but for local communication as
well. For example, two people with laptop computers supporting IEEE
802.11 Wireless LANs [802.11] may meet and wish to exchange files.
It is desirable for these people to be able to use IP application
software without the inconvenience of having to manually configure
static IP addresses or set up a DHCP server [RFC2131].
This document describes a method by which a host may automatically
configure an interface with an IPv4 address in the 169.254/16 prefix
that is valid for Link-Local communication on that interface. This
is especially valuable in environments where no other configuration
mechanism is available. The IPv4 prefix 169.254/16 is registered
with the IANA for this purpose. Allocation of IPv6 Link-Local
addresses is described in "IPv6 Stateless Address Autoconfiguration"
[RFC2462].
Link-Local communication using IPv4 Link-Local addresses is only
suitable for communication with other devices connected to the same
physical (or logical) link. Link-Local communication using IPv4
Link-Local addresses is not suitable for communication with devices
not directly connected to the same physical (or logical) link.
Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already
support this capability. This document standardizes usage,
prescribing rules for how IPv4 Link-Local addresses are to be treated
by hosts and routers. In particular, it describes how routers are to
behave when receiving packets with IPv4 Link-Local addresses in the
source or destination address. With respect to hosts, it discusses
claiming and defending addresses, maintaining Link-Local and routable
IPv4 addresses on the same 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 document describes Link-Local addressing, for IPv4 communication
between two hosts on a single link. A set of hosts is considered to
be "on the same link", if:
- 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, and
- a broadcast sent over that link by any host from that set of hosts
can be received by every other host in that set
The link-layer *header* may be modified, such as in Token Ring Source
Routing [802.5], but not the link-layer *payload*. In particular, if
any device forwarding a packet modifies any part of the IP header or
IP payload then the packet is no longer considered to be on the same
link. This means that the packet may pass through devices such as
repeaters, bridges, hubs or switches and still be considered to be on
the same link for the purpose of this document, but not through a
device such as an IP router that decrements the TTL or otherwise
modifies the IP header.
This document uses the term "routable address" to refer to all valid
unicast IPv4 addresses outside the 169.254/16 prefix that may be
forwarded via routers. This includes all global IP addresses and
private addresses such as Net 10/8 [RFC1918], but not loopback
addresses such as 127.0.0.1.
Wherever this document uses the term "host" when describing use of
IPv4 Link-Local addresses, the text applies equally to routers when
they are the source of or intended destination of packets containing
IPv4 Link-Local source or destination addresses.
Wherever this document uses the term "sender IP address" or "target
IP address" in the context of an ARP packet, it is referring to the
fields of the ARP packet identified in the ARP specification [RFC826]
as "ar$spa" (Sender Protocol Address) and "ar$tpa" (Target Protocol
Address) respectively. For the usage of ARP described in this
document, each of these fields always contains an IP address.
In this document, the term "ARP Probe" is used to refer to 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 document, the term "ARP Announcement" is used to refer to an
ARP Request packet, broadcast on the local link, identical to the ARP
Probe described above, except that both the sender and target IP
address fields contain the IP address being announced.
Constants are introduced in all capital letters. Their values are
given in Section 9.
1.3. Applicability
This specification applies to all IEEE 802 Local Area Networks (LANs)
[802], including Ethernet [802.3], Token-Ring [802.5] and IEEE 802.11
wireless LANs [802.11], as well as to other link-layer technologies
that operate at data rates of at least 1 Mbps, have a round-trip
latency of at most one second, and support ARP [RFC826]. Wherever
this document uses the term "IEEE 802", the text applies equally to
any of these network technologies.
Link-layer technologies that support ARP but operate at rates below 1
Mbps or latencies above one second may need to specify different
values for the following 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
Link-layer technologies that do not support ARP may be able to use
other techniques for determining whether a particular IP address is
currently in use. However, the application of claim-and-defend
mechanisms to such networks is outside the scope of this document.
This specification is intended for use with small ad hoc networks --
a single link containing only a few hosts. Although 65024 IPv4
Link-Local addresses are available in principle, attempting to use
all those addresses on a single link would result in a high
probability of address conflicts, requiring a host to take an
inordinate amount of time to find an available address.
Network operators with more than 1300 hosts on a single link may want
to consider dividing that single link into two or more subnets. A
host connecting to a link that already has 1300 hosts, selecting an
IPv4 Link-Local address at random, has a 98% chance of selecting an
unused IPv4 Link-Local address on the first try. A host has a 99.96%
chance of selecting an unused IPv4 Link-Local address within two
tries. The probability that it will have to try more than ten times
is about 1 in 10^17.
1.4. Application Layer Protocol Considerations
IPv4 Link-Local addresses and their dynamic configuration have
profound implications upon applications which use them. This is
discussed in Section 6. Many applications fundamentally assume that
addresses of communicating peers are routable, relatively unchanging
and unique. These assumptions no longer hold with IPv4 Link-Local
addresses, or a mixture of Link-Local and routable IPv4 addresses.
Therefore while many applications will work properly with IPv4 Link-
Local addresses, or a mixture of Link-Local and routable IPv4
addresses, others may do so only after modification, or will exhibit
reduced or partial functionality.
In some cases it may be infeasible for the application to be modified
to operate under such conditions.
IPv4 Link-Local addresses should therefore only be used where stable,
routable addresses are not available (such as on ad hoc or isolated
networks) or in controlled situations where these limitations and
their impact on applications are understood and accepted. This
document does not recommend that IPv4 Link-Local addresses and
routable addresses be configured simultaneously on the same
interface.
Use of IPv4 Link-Local addresses in off-link communication is likely
to cause application failures. This can occur within any application
that includes embedded addresses, if an IPv4 Link-Local address is
embedded when communicating with a host that is not on the link.
Examples of applications that embed addresses include IPsec, Kerberos
4/5, FTP, RSVP, SMTP, SIP, X-Windows/Xterm/Telnet, Real Audio, H.323,
and SNMP [RFC3027].
To preclude use of IPv4 Link-Local addresses in off-link
communication, the following cautionary measures are advised:
a. IPv4 Link-Local addresses MUST NOT be configured in the DNS.
b. Names that are globally resolvable to routable addresses should be
used within applications whenever they are available. Names that
are resolvable only on the local link (such as through use of
protocols such as 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 hinder
limited scope addresses and names from leaving the context in
which they apply.
c. If names resolvable to globally routable addresses are not
available, but the globally routable addresses 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, and MUST be prepared to handle them
gracefully by automatically selecting a new address whenever a
conflict is detected, as described in Section 2. This requirement to
detect and handle address conflicts applies during the entire period
that a host is using a 169.254/16 IPv4 Link-Local address, not just
during initial interface configuration. For example, address
conflicts can occur well after a host has completed booting if two
previously separate networks are joined, as described in Section 4.
1.6. Alternate Use Prohibition
Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
manually or by a DHCP server. Manual or DHCP configuration may cause
a host to use an address in the 169.254/16 prefix without following
the special rules regarding duplicate detection and automatic
configuration that pertain to addresses in this prefix. While the
DHCP specification [RFC2131] indicates that a DHCP client SHOULD
probe a newly received address with ARP, this is not mandatory.
Similarly, while the DHCP specification recommends that a DHCP server
SHOULD probe an address using an ICMP Echo Request before allocating
it, this is also not mandatory, and even if the server does this,
IPv4 Link-Local addresses are not routable, so a DHCP server not
directly connected to a link cannot detect whether a host on that
link is already using the desired IPv4 Link-Local address.
Administrators wishing 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
Additional considerations apply to hosts that support more than one
active interface where one or more of these interfaces support IPv4
Link-Local address configuration. These considerations are discussed
in Section 3.
1.8. Communication with Routable Addresses
There will be cases when devices with a configured Link-Local address
will need to communicate with a device with a routable address
configured on the same physical link, and vice versa. The rules in
Section 2.6 allow this communication.
This allows, for example, a laptop computer with only a routable
address to communicate with web servers world-wide using its
globally-routable address while at the same time printing those web
pages on a local printer that has only an IPv4 Link-Local address.
1.9. When to configure an IPv4 Link-Local address
Having addresses of multiple different scopes assigned to an
interface, with no adequate way to determine in what circumstances
each address should be used, leads to complexity for applications and
confusion for users. A host with an address on a link can
communicate with all other devices on that link, whether those
devices use Link-Local addresses, or routable addresses. For these
reasons, a host SHOULD NOT have both an operable routable address and
an IPv4 Link-Local address configured on the same interface. The
term "operable address" is used to mean an address which works
effectively for communication in the current network context (see
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. However, during the transition (in either
direction) between using routable and IPv4 Link-Local addresses both
MAY be in use at once subject to these rules:
1. The assignment of an IPv4 Link-Local address on an interface is
based solely on the state of the interface, and is independent
of any other protocols such as DHCP. A host MUST NOT alter its
behavior and use of other protocols such as DHCP because the
host has assigned an IPv4 Link-Local address to an interface.
2. If a host finds that an interface that was previously
configured with an IPv4 Link-Local address now has an operable
routable address available, the host MUST use the routable
address when initiating new communications, and MUST cease
advertising the availability of the IPv4 Link-Local address
through whatever mechanisms that address had been made known to
others. The host SHOULD continue to use the IPv4 Link-Local
address for communications already underway, and MAY continue
to accept new communications addressed to the IPv4 Link-Local
address. Ways in which 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
3. 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 in which an operable routable
address might cease to be 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 determination by the system of whether an address is "operable"
is not clear cut and many changes in the system context (e.g.,
router changes) may affect the operability of an address. In
particular roaming of a host from one network to another is likely --
but not certain -- to change the operability of a configured address
but detecting such a move is not always trivial.
"Detection of Network Attachment (DNA) in IPv4" [DNAv4] provides
further discussion of address assignment and operability
determination.
2. Address Selection, Defense and Delivery
The following section explains the IPv4 Link-Local address selection
algorithm, how IPv4 Link-Local addresses are defended, and how IPv4
packets with IPv4 Link-Local addresses are delivered.
Windows and Mac OS hosts that already implement Link-Local IPv4
address auto-configuration are compatible with the rules presented 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 wishes to configure an IPv4 Link-Local address, it
selects an address using a pseudo-random number generator with a