it is not necessary for that host to have a Link-Local source address
in order to send to a Link-Local destination address.
A host with an IPv4 Link-Local address may send to a destination
which does not have an IPv4 Link-Local address. If the host is not
multi-homed, the procedure is simple and unambiguous: Using ARP and
forwarding directly to on-link destinations is the default route. If
the host is multi-homed, however, the routing policy is more complex,
especially if one of the interfaces is configured with a routable
address and the default route is (sensibly) directed at a router
accessible through that interface. The following example illustrates
this problem and provides a common solution to it.
i1 +---------+ i2 i3 +-------+
ROUTER-------= HOST1 =---------= HOST2 |
link1 +---------+ link2 +-------+
In the figure above, HOST1 is connected to link1 and link2.
Interface i1 is configured with a routable address, while i2 is 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
to 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 is a route from ROUTER to HOST2, the
datagrams sent from HOST1 to HOST2 will not reach it.
One solution to this problem is for a host to attempt to reach any
host locally (using ARP) for which it receives 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 circumvent exactly
this problem. In terms of this example, HOST1 upon 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 techniques
described in section 3.2, or other means not discussed here. This
specification does not provide a standard solution, nor does it
preclude implementers from supporting multi-homed configurations,
provided that they address the concerns in this section for the
applications which will be supported on the host.
3.4. Unintentional Autoimmune Response
Care must be taken if a multi-homed host can support more than one
interface on the same link, all of which support IPv4 Link-Local
autoconfiguration. If these interfaces attempt to allocate the same
address, they will defend the host against itself -- causing the
claiming algorithm to fail. The simplest solution to this problem is
to run the algorithm independently on each interface configured with
IPv4 Link-Local addresses.
In particular, ARP packets which appear to claim an address which is
assigned to a specific interface, indicate conflict only if they are
received on that interface and their hardware address is of some
other interface.
If a host has two interfaces on the same link, then claiming and
defending on those interfaces must ensure that they end up with
different addresses just as if they were on different hosts. Note
that some of the ways a host may find itself with two interfaces on
the same link may be unexpected and non-obvious, such as when a host
has Ethernet and 802.11 wireless, but those two links are (possibly
even without the knowledge of the host’s user) bridged together.
4. Healing of Network Partitions
Hosts on disjoint network links may configure the same IPv4 Link-
Local address. If these separate network links are later joined or
bridged together, then there may be two hosts which are now on the
same link, trying to use the same address. When either host attempts
to communicate with any other host on the network, it will at some
point broadcast an ARP packet which will enable the hosts in question
to detect that there is an address conflict.
When these address conflicts are detected, the subsequent forced
reconfiguration may be disruptive, causing TCP connections to be
broken. However, it is expected that such disruptions will be rare.
It should be relatively uncommon for networks to be joined while
hosts on those networks are active. Also, 65024 addresses are
available for IPv4 Link-Local use, so even when two small networks
are joined, the chance of conflict for any given host is fairly
small.
When joining two large networks (defined as networks with a
substantial number of hosts per segment) there is a greater chance of
conflict. In such networks, it is likely that the joining of
previously separated segments will result in one or more hosts
needing to change their IPv4 Link-Local address, with subsequent loss
of TCP connections. In cases where separation and re-joining is
frequent, as in remotely bridged networks, this could prove
disruptive. However, unless the number of hosts on the joined
segments is very large, the traffic resulting from the join and
subsequent address conflict resolution will be small.
Sending ARP replies that have IPv4 Link-Local sender addresses via
broadcast instead of unicast ensures that these conflicts can be
detected as soon as they become potential problems, but no sooner.
For example, if two disjoint network links are joined, where hosts A
and B have both configured the same Link-Local address, X, they can
remain in this state until A, B or some other host attempts to
initiate communication. If some other host C now sends an ARP
request for address X, and hosts A and B were to both reply with
conventional unicast ARP replies, then host C might be confused, but
A and B still wouldn’t know there is a problem because neither would
have seen the other’s packet. Sending these replies via broadcast
allows A and B to see each other’s conflicting ARP packets and
respond accordingly.
Note that sending periodic gratuitous ARPs in an attempt to detect
these conflicts sooner is not necessary, wastes network bandwidth,
and may actually be detrimental. For example, if the network links
were joined only briefly, and were separated again before any new
communication involving A or B were initiated, then the temporary
conflict would have been benign and no forced reconfiguration would
have been required. Triggering an unnecessary forced reconfiguration
in this case would not 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 to new
attacks. In particular, a host that previously did not have an IP
address, and no IP stack running, was not susceptible to IP-based
attacks. By configuring a working address, the host may now be
vulnerable to IP-based attacks.
The ARP protocol [RFC826] is insecure. A malicious host may send
fraudulent ARP packets on the network, interfering with the correct
operation of other hosts. For example, it is easy for a host to
answer all ARP requests with replies giving its own hardware address,
thereby claiming ownership of every address on the network.
NOTE: There are certain kinds of local links, such as wireless LANs,
that provide no physical security. Because of the existence of these
links it would be very unwise for an implementer to assume that when
a device is communicating only on the local link it can dispense with
normal security precautions. Failure to implement appropriate
security measures could expose users to considerable risks.
A host implementing IPv4 Link-Local configuration has an additional
vulnerability to selective reconfiguration and disruption. It is
possible for an on-link attacker to issue ARP packets which would
cause a host to break all its connections by switching to a new
address. The attacker could force the host implementing IPv4 Link-
Local configuration to select certain addresses, or prevent it from
ever completing address selection. This is a distinct threat from
that posed by spoofed ARPs, described in the preceding paragraph.
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 must implement security which
is adequate to protect the resources to which the device or host has
access, including the network itself, against known or credible
threats. Even though use of IPv4 Link-Local addresses may reduce the
number of threats to which a device is exposed, implementers of
devices supporting the Internet Protocol must not assume that a
customer’s local network is free from security risks.
While there may be particular kinds of devices, or particular
environments, for which the security provided by the network is
adequate to protect the resources that are accessible by the device,
it would be misleading to make a general statement to the effect that
the requirement to provide security is reduced for devices using IPv4
Link-Local addresses as a sole means of access.
In all cases, whether or not IPv4 Link-Local addresses are used, it
is necessary for implementers of devices supporting the Internet
Protocol to analyze the known and credible threats to which a
specific host or device might be subjected, and to the extent that it
is feasible, to provide security mechanisms which ameliorate or
reduce the risks associated with such threats.
6. Application Programming Considerations
Use of IPv4 Link-Local autoconfigured addresses presents additional
challenges to writers of applications and may result in existing
application software failing.
6.1. Address Changes, Failure and Recovery
IPv4 Link-Local addresses used by an application may change over
time. Some application software encountering an address change will
fail. For example, existing client TCP connections will be aborted,
servers whose addresses change will have to be rediscovered, blocked
reads and writes will exit with an error condition, and so on.
Vendors producing application software which will be used on IP
implementations supporting IPv4 Link-Local address configuration
SHOULD detect and cope with address change events. Vendors producing
IPv4 implementations supporting 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. Suppose a
client starts up and obtains its IPv4 configuration at a time when it
has only 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 transmits its old Link-Local address instead
of its new global IP address in the FTP "port" command, then the FTP
server will be unable to open a data connection back to the client,
and the FTP operation will fail.
6.3. Address Ambiguity
Application software run on a multi-homed host that supports IPv4
Link-Local address configuration on more than one interface may fail.
This is because application software assumes that an IPv4 address is
unambiguous, that it can refer to only one host. IPv4 Link-Local
addresses are unique only on a single link. A host attached to
multiple links can easily encounter a situation where the same
address is present on more than one interface, or first on one
interface, later on another; in any case associated with more than
one host. Most existing software is not prepared 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, irrespective of the router’s default route
configuration or routes obtained from dynamic routing protocols.
A router which receives a packet with an IPv4 Link-Local source or
destination address MUST NOT forward the packet. This prevents
forwarding of packets back onto the network segment from which they
originated, or to 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 intended 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
[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
We would like to thank (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.
Appendix A - Prior Implementations
A.1. Apple Mac OS 8.x and 9.x.
Mac OS chooses the IP address on a pseudo-random basis. The selected
address is saved in persistent storage for continued use after
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 chooses the IP address on a pseudo-random basis. The
selected address is saved in memory so that 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