[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-cheshire-ipv4-linklocal) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 3927

ZEROCONF Working Group                                   Stuart Cheshire
INTERNET-DRAFT                                            Apple Computer
Category: Standards Track                                  Bernard Aboba
<draft-ietf-zeroconf-ipv4-linklocal-08.txt>        Microsoft Corporation
3 June 2003                                                 Erik Guttman
                                                        Sun Microsystems

           Dynamic Configuration of Link-Local IPv4 Addresses

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

To participate in wide-area IP networking, a host needs to be
configured, either manually by the user or automatically from a source
on the network such as a DHCP server.  Unfortunately, such external
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
network to always be functional, even when no configuration information
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. Communication using Link-Local IPv4
addresses is not suitable for communication with devices not directly
connected to the same physical (or logical) link.






Cheshire, et al.             Standards Track                    [Page 1]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


Table of Contents

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








Cheshire, et al.             Standards Track                    [Page 2]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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 Link-Local IPv6 addresses is
described in "IPv6 Stateless Address Autoconfiguration" [RFC2462].

Link-Local communication using Link-Local IPv4 addresses is only
suitable for communication with other devices connected to the same
physical (or logical) link. Link-Local communication using Link-Local
IPv4 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 Link-Local IPv4 addresses MUST be treated by hosts and
routers. In particular, it describes how routers MUST 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 multihoming issues.

1.1.  Requirements

In this document, several words are used to signify the requirements of
the specification.  These words are often capitalized.  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 [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:




Cheshire, et al.             Standards Track                    [Page 3]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


- 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 unicast
IPv4 addresses outside the 169.254/16 prefix, including global addresses
and private addresses such as Net 10/8 [RFC1918], all of which may be
forwarded via routers.

Wherever this document uses the term "host" when describing use of Link-
Local IPv4 addresses, the text applies equally to routers using Link-
Local IPv4 addresses on any or all interfaces.

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.







Cheshire, et al.             Standards Track                    [Page 4]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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 described in Sections 2.2, 2.3 and 2.4:

(a) the number of, and interval between, ARP probes,
(b) the number of, and interval between, ARP announcements,
(c) the maximum rate at which address claiming may be attempted, and
(d) the time interval between conflicting ARPs below which a host
MUST reconfigure instead of attempting to defend its address.

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 Link-Local IPv4
addresses are available in principle, attempting to use all those
addresses on a single link would result a high probability of an address
conflict, 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 a Link-Local
IPv4 address at random, has a 98% chance of selecting an unused Link-
Local IPv4 address on the first try. A host has a 99.96% chance of
selecting an unused Link-Local IPv4 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

Use of Link-Local IPv4 addresses in off-link communication is likely to
cause application failures. This can occur within any application that
includes embedded addresses, if a Link-Local IPv4 address is embedded
when communicating with a host that is not on the link. Examples of
applications that include embedded addresses are found in [RFC3027].



Cheshire, et al.             Standards Track                    [Page 5]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


This includes IPsec, Kerberos 4/5, X-Windows/Xterm/Telnet, FTP, RSVP,
SMTP, SIP, Real Audio, H.323, and SNMP.

In order to prevent use of Link-Local IPv4 addresses in off-link
communication, the following cautionary measures are advised:

a. Routable addresses should be used within applications whenever they
are available.

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. This can be prevented by using Link-Local IPv4
addresses or names resolvable on the local link when a Link-Local IPv4
address is used as the source address in the packet.

c. Link-Local IPv4 addresses MUST NOT be configured in the DNS.

Link-Local IPv4 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 Link-Local IPv4 addresses, or a
mixture of Link-Local and routable IPv4 addresses. Therefore while many
applications will work properly with Link-Local IPv4 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.

Link-Local IPv4 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.

1.5.  Autoconfiguration Issues

Implementations of Link-Local IPv4 address autoconfiguration MUST expect
address collisions, and MUST be prepared to handle them gracefully by
automatically selecting a new address whenever a collision is detected,
as described in Section 2. This requirement to detect and handle address
collisions applies during the entire period that a host is using a
169.254/16 Link-Local IPv4 address, not just during initial interface
configuration. For example, address collisions can occur well after a
host has completed booting if two previously separate networks are
joined, as described in Section 4.



Cheshire, et al.             Standards Track                    [Page 6]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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 [RFC2131] indicates that
a DHCP client SHOULD probe a newly received address with ARP, this is
not mandatory. Similarly, while [RFC2131] 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, Link-Local
IPv4 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 Link-Local IPv4 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 Addresses per Interface

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 this reason, a host that obtains, or is configured with, a routable
address on an interface, SHOULD NOT attempt to configure a Link-Local
IPv4 address on the same interface.

Where a Link-Local IPv4 address has been configured on an interface, and
a routable address is later configured on the same interface, the host
MUST always use the routable address when initiating new communications,
and MUST cease advertising the availability of the Link-Local IPv4
address through whatever mechanisms that address had been made known to
others.

A host SHOULD continue to use the Link-Local IPv4 address for
communications underway when the routable address was configured, and
MAY continue to accept new communications addressed to the Link-Local
IPv4 address.







Cheshire, et al.             Standards Track                    [Page 7]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


1.8.  Multiple Interfaces

Hosts that support multi-homing have additional considerations if they
wish to use Link-Local IPv4 addresses on more than one interface at a
time. These are discussed in Section 3.

1.9.  Communication with Routable Addresses

For some devices, engineering constraints may mean that it is only
possible to implement a single address per interface, either Link-Local
or routable, but not both at the same time. For this reason, the rules
in Section 2.6 allow communication from a routable source address to a
Link-Local IPv4 destination address on the same physical link, and vice
versa. 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 a Link-Local IPv4 address.

2.  Address Selection, Defense and Delivery

The following section explains the Link-Local IPv4 address selection
algorithm, how Link-Local IPv4 addresses are defended, and how IPv4
packets with Link-Local IPv4 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 a Link-Local IPv4 address, it selects an
address using a pseudo-random number generator with a uniform
distribution in the range from 169.254.1.0 to 169.254.254.255. 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 Link-Local IPv4 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



Cheshire, et al.             Standards Track                    [Page 8]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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 though 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 a Link-Local IPv4 address, a host MUST test to see
if the Link-Local IPv4 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 Link-Local IPv4
addresses may currently be in use on that link, since the network
interface may have been inactive when a conflicting address was claimed.

Were it immediately to begin using a Link-Local IPv4 address which is
already in use by another host, this would be disruptive to that other
host. For this reason, before using the Link-Local IPv4 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 Link-Local IPv4
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 that indicates that a
        cable was attached.
   Association with a wireless base station.

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.




Cheshire, et al.             Standards Track                    [Page 9]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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 left to a future
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 one seconds, and should
then send three probe packets, spaced randomly, zero to one seconds
apart.

If during this period, from the beginning of the probing process until
two seconds after the last probe packet is sent, the host receives any
ARP packet (Request *or* Reply) 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 any of the host's interfaces, then the
host MUST similarly treat this as an address collision and select a new
address as above. This can occur if two (or more) hosts attempt to
configure the same Link-Local IPv4 address at the same time.

A host should maintain a counter of the number of address collisions it
has experienced in the process of trying to acquire an address, and if
the number of collisions exceeds ten then the host MUST limit the rate
at which it probes for new addresses to no more than one new address per
minute. 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.




Cheshire, et al.             Standards Track                   [Page 10]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


If, by two seconds after the transmission of the last ARP probe no
conflicting ARP Reply has been received, then the host has successfully
claimed the desired Link-Local IPv4 address.

2.3.  Shorter timeouts

The time values specified above are intended for use on technologies
such as IEEE 802, where switches that implement Spanning Tree [802.1d]
often silently discard all packets for several seconds. The time values
specified above result in a delay of 8-10 seconds before a chosen IP
address may be used. For a desktop machine on an IEEE 802 LAN, this may
not be a great problem, but for other types of device, particularly
portable hand-held wireless devices, a ten-second delay before
networking services becomes available may not be acceptable.  For this
reason, shorter time values may be used on network technologies that
allow the device to determine when the link has become active and can be
reasonably trusted to deliver packets reliably. On these network
technologies the recommended time values are: The host should first wait
for a random time interval selected uniformly in the range 0-200
milliseconds, and then send four probe packets, waiting 200 milliseconds
after each probe, making a total delay of 800-1000 milliseconds before a
chosen IPv4 address may be used.

Should future versions of the IEEE 802 Spanning Tree Protocol be
enhanced to inform clients when the link is ready to begin forwarding
packets, then the shorter time values may be used on these networks too.

2.4.  Announcing an Address

The host MUST then announce its claimed address by broadcasting two ARP
announcements, spaced two seconds apart. This time interval is not
modified by the shorter timeouts described above in Section 2.3.  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 collision detection is not limited to the address selection
phase, when a host is sending ARP probes. Address collision detection is
an ongoing process that is in effect for as long as a host is using a
Link-Local IPv4 address. At any time, if a host receives an ARP packet
(request *or* reply) where the 'sender IP address' is the host's own IP
address, but the 'sender hardware address' does not match any of the
host's own interface addresses, then this is a conflicting ARP packet,



Cheshire, et al.             Standards Track                   [Page 11]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


indicating an address collision. 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 Link-Local IPv4 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 recently (for IEEE 802, within the last ten
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 ten seconds for IEEE 802) then
the host MUST immediately cease using this address and configure a new
Link-Local IPv4 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.

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.







Cheshire, et al.             Standards Track                   [Page 12]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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 a Link-Local IPv4
address.

2.6.1.  Source Address Usage

Since each interface on a host may have a Link-Local IPv4 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.

The host SHOULD use a routable address in preference to a Link-Local
IPv4 address except for communication to peers for which the host has an
existing TCP connection at the time in which the host obtained a
routable address configuration.  For more details, see Section 1.7.

If the host is multihomed, the decision as to which source address to
use is more difficult.  This specification does not define how the host
operates in this case, although it describes the issues involved and
provides advice (see Section 3).

2.6.2.  Forwarding Rules

If the destination address is in the 169.254/16 prefix (including the
169.254.255.255 broadcast address), 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.

The host MUST NOT send a packet with a Link-Local IPv4 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 has one. If the host does not have a routable source
address, then it MAY choose to ARP for the destination address and then
send its packet, with a Link-Local IPv4 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.




Cheshire, et al.             Standards Track                   [Page 13]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


If the host is multihomed, determining the rules on how to forward to a
destination are more complex.  This specification does not define
multihomed operation.  Rather, the issues are explained and advice is
given on how to address known problems (see Section 3).

2.7.  Link-Local Packets Are Not Forwarded

A sensible default for applications which are sending from a Link-Local
IPv4 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 Link-Local IPv4 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 off 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 collision 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.

The non-forwarding rule is important because it is expected that Link-
Local-only devices will often be simple devices of the kind that
currently use X10 [X10], USB [USB] or FireWire [1394].

The designers of these devices currently assume that they will
communicate only with other local devices, and this allows them to
produce cost-effective devices by implementing a degree of security
appropriate for that expected environment. Any network gateway device
that blindly forwards the contents of Link-Local IPv4 packets off the
local link (or onto the local link) exposes simple Link-Local-only
devices to a much greater degree of risk than their designers may have
planned for.



Cheshire, et al.             Standards Track                   [Page 14]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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.

Simple devices that implement only a Link-Local IPv4 address may also
communicate with hosts outside the local link, provided that such
communication is mediated through a device capable of enforcing
appropriate security controls. For example, a home heating thermostat
that implements only a Link-Local IPv4 address could be controlled from
a remote Web browser, by having an intermediary on the local network
which accepts incoming HTTP connections, uses appropriate cryptographic
methods to verify the authority of the remote user, and then uses Link-
Local IPv4 packets to communicate with the thermostat to get status and
issue commands.

It should be understood that this mediated communication is not
mandatory; it is an option afforded to designers of extremely simple
devices. Any designer of a device desiring unmediated communication
outside the local link need only implement today's conventional IP host
software (e.g. a DHCP client) in order to enjoy the same degree of
global addressability available to other conventional IPv4 hosts.  Such
networked devices should of course implement a degree of security
appropriate to being connected to a global public network.

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 Link-Local IPv4
addresses if those pages are viewable from hosts outside the local link
where the addresses are valid.

As Link-Local IPv4 addresses may change at any time and have limited
scope, storing Link-Local IPv4 addresses in the DNS is not well
understood and is NOT RECOMMENDED.

2.10.  Privacy Concerns

Another reason to restrict leakage of Link-Local IPv4 addresses outside
the local link is privacy concerns. If Link-Local IPv4 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 Link-Local IPv4
addresses don't leave the local link they provide no more information to
an intruder than could be gained by direct observation of hardware



Cheshire, et al.             Standards Track                   [Page 15]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


addresses.

3.  Considerations for Multiple Interfaces

These considerations 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 "multihoming".

Hosts which have more than one active interface and elect to implement
dynamic configuration of Link-Local IPv4 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 multihoming.

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 Link-Local IPv4 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 source address of the
sender to whom the application will reply.

The first scoped address problem is source address selection. A
multihomed host has more than one address. Which address should be used
as the source address when sending to a particular destination? This
answer is usually answered by referring to a routing table, which
expresses 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.



Cheshire, et al.             Standards Track                   [Page 16]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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, 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
multihoming problems.

3.2.  Address Ambiguity

This is a core problem with respect to Link-Local IPv4 addresses
configured 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?

One possibility is to support this only in the case where the
application specifically expresses which interface to send from.

There no standard or obvious solution to this problem.  Existing
application software written for the Internet 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 Link-Local IPv4 addresses on more than one interface.  This solution
will almost surely not be generally applicable to existing software and
transparent to higher layers, however.

3.3.  Interaction with Hosts with Routable Addresses

Attention is paid in this specification to transition from the use of
Link-Local IPv4 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 will not advertise scoped address information, the scoped
address issues described in Section 3.1 will apply. A host which
conforms to this specification will know that a Link-Local IPv4
destination must be reached by forwarding to the destination, not to a
router, even if the host is sending from a routable address.




Cheshire, et al.             Standards Track                   [Page 17]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


A host with a Link-Local IPv4 address may send to a destination which
does not have a Link-Local IPv4 address. If the host is not multihomed,
the procedure is simple and unambiguous: Using ARP and forwarding
directly to on-link destinations is the default route. If the host is
multihomed, 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 a Link-Local IPv4
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, see [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 multihomed configurations, provided that
they address the concerns in this section for the applications which
will be supported on the host.

3.4.  Unintentional Autoimmunity

Care must be taken if a multihomed host can support more than one
interface on the same link, all of which support Link-Local IPv4
autoconfiguration. If these interfaces attempt to allocate the same



Cheshire, et al.             Standards Track                   [Page 18]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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 Link-Local
IPv4 addresses.

4.  Healing of Network Partitions

Hosts on disjoint network links may configure the same Link-Local IPv4
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 Link-Local
IPv4 use, so even when two small networks are joined, the chance of
collision 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 collision. In
such networks, it is likely that the joining of previously separated
segments will result in one or more hosts needing to change their Link-
Local IPv4 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 Link-Local sender IPv4 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 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



Cheshire, et al.             Standards Track                   [Page 19]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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: The existence of local links without physical security, such as
LANs with attached wireless base stations, means that expecting all
local links to be secure enough that normal precautions can be dispensed
with is an extremely dangerous practice, which will expose users to
considerable risks.

A host implementing Link-Local IPv4 configuration has the 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 Link-Local IPv4 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 successfully hijack existing
TCP connections. Before abandoning an address due to a conflict, hosts
SHOULD actively attempt to reset any existing connections using that
address.

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



Cheshire, et al.             Standards Track                   [Page 20]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


though use of Link-Local IPv4 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 Link-Local
IPv4 addresses as a sole means of access.

In all cases, whether or not Link-Local IPv4 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 Link-Local IPv4 autoconfigured addresses presents additional
challenges to writers of applications and may result in existing
application software failing.

6.1.  Address Changes, Failure and Recovery

Link-Local IPv4 addresses used by an application may change over time.
Some application software encountering an address change will completely
fail. For example, client TCP connections will fail, 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 Link-Local IPv4 address configuration SHOULD
detect and cope with address change events. Vendors producing IPv4
implementations supporting Link-Local IPv4 address configuration SHOULD
expose address change events to applications.

6.2.  Limited Forwarding of Locators

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

Existing distributed application software which forwards address
information may fail. For example, FTP [RFC 959] passive mode transmits
the IPv4 address of the client. Assume a client starts up and obtains



Cheshire, et al.             Standards Track                   [Page 21]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


its *passive* IPv4 configuration at a time when the host has only a
Link-Local address. Later, the host gets a global IP address
configuration (for one of its interfaces). The client uses this global
IPv4 address to contact an FTP server off of the local link for which it
had (or still has) a Link-Local IPv4 address configured. If the FTP
client transmits its passive IPv4 configuration to the FTP server, the
FTP server will be unable to reach the FTP client. The passive FTP
operation will fail.

6.3.  Address Ambiguity

Application software run on a multihomed host which supports Link-Local
IPv4 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.  Link-Local IPv4
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 which receives a packet with a Link-Local IPv4 destination
address on an interface which either has no Link-Local IPv4 address
configured or a different address than the destination of the packet
MUST NOT forward the packet.   This will prevent forwarding of packets
back onto the network segment from which they originated and to any
other segment.

A router MUST NOT forward a packet with a Link-Local IPv4 source or
destination address, irrespective of the router's default route
configuration or routes obtained from dynamic routing protocols.

8.  IANA Considerations

The following terms are used here with the meanings defined in BCP 26:
"name space", "assigned value", "registration".

The following policies are used here with the meanings defined in BCP
26: "Private Use", "First Come First Served", "Expert Review",
"Specification Required", "IESG Approval", "IETF Consensus", "Standards
Action".

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



Cheshire, et al.             Standards Track                   [Page 22]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


(169.254.0.x and 169.254.255.x) are allocated by Standards Action. No
other IANA services are required by this document.

9.  Normative References

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

[RFC826]       D. Plummer, "An Ethernet Address Resolution Protocol -or-
               Converting Network Addresses to 48-bit Ethernet Address
               for Transmission on Ethernet Hardware", STD 37, RFC 826,
               November 1982.

[RFC1122]      R. Braden, "Requirements for Internet Hosts --
               Communication Layers", RFC 1122, October 1989.

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

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

10.  Informative References

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

[802.1d]       ISO/IEC 15802-3 Information technology -
               Telecommunications and information exchange between
               systems - Local and metropolitan area networks - Common
               specifications - Part 3: Media access Control (MAC)
               Bridges, (also ANSI/IEEE Std 802.1D-1998), 1998.

[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.



Cheshire, et al.             Standards Track                   [Page 23]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


[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.

[1394]         Standard for a High Performance Serial Bus.  Institute of
               Electrical and Electronic Engineers, IEEE Standard
               1394-1995, 1995.

[RFC1918]      Y. Rekhter et.al., "Address Allocation for Private
               Internets", RFC 1918, February 1996.

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

[RFC2181]      R. Elz and R. Bush, "Clarifications to the DNS
               Specification", RFC 2181, July 1997.

[RFC2462]      S. Thomson 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.

[LLMNR]        Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast
               Name Resolution (LLMNR)", draft-ietf-dnsext-mdns-20.txt,
               Internet draft (work in progress), May 2003.

[USB]          Universal Serial Bus Implementers Forum
               <http://www.usb.org/>

[X10]          X10 Ltd. <http://www.x10.com/>

Acknowledgments

We would like to thank (in alphabetical order) Jim Busse, Pavani
Diwanji, Donald Eastlake 3rd, Peter Ford, Spencer Giacalone, Josh
Graessley, Myron Hattig, Hugh Holbrook, Richard Johnson, Kim Yong-Woon,
Rod Lopez, Keith Moore, Satish Mundra, Thomas Narten, Erik Nordmark,
Howard Ridenour, Daniel Senie, Dieter Siegmund, Valery Smyslov and Ryan
Troll for their contributions.







Cheshire, et al.             Standards Track                   [Page 24]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


Authors' Addresses

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 706 6605
EMail: bernarda@microsoft.com

Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt Germany

Phone: +49 7263 911 701
Email: erik.guttman@sun.com

























Cheshire, et al.             Standards Track                   [Page 25]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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



Cheshire, et al.             Standards Track                   [Page 26]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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 Link-Local IPv4 address on a
pseudo-random basis. This ensures that systems rebooting will obtain the
same autoconfigured address, unless a conflict is detected. 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.

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.



Cheshire, et al.             Standards Track                   [Page 27]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


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 Link-Local IPv4 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 Link-Local IPv4 address.

Windows 98/98SE systems with a Link-Local IPv4 address do not send
packets addressed to a Link-Local IPv4 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.  There is no way a host can distinguish between
packets generated locally with a TTL of 128, and packets generated by a
remote attacker, deliberately constructed with a spoofed source address
in the 169.254/16 prefix, and a TTL higher than 128, such that after
passing through one or more misconfigured routers, the TTL will have
decremented to 128 by the time it reaches the target network.  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 so that it cannot be
used to set the default TTL of Link-Local IPv4 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 mini-DHCP server included with Windows 98SE Internet Connection
Sharing (ICS), which functions as a NAT, 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 Link-Local
IPv4 prefix. When configured to do so, Windows 98SE ICS will NAT packets
from the Link-Local prefix off the local link. Windows 98SE ICS does not



Cheshire, et al.             Standards Track                   [Page 28]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


automatically route for the 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 Link-Local
prefix by default. Windows 98/98SE systems can use a 169.254/16 Link-
Local IPv4 address as the source address when communicating with non-
Link-Local hosts. However, Windows 98/98SE does not support router
solicitation/advertisement. This means that Windows 98/98SE systems will
typically not be able to 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 it is possible to 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.


















Cheshire, et al.             Standards Track                   [Page 29]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


Intellectual Property Statement

The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this document.
For more information consult the online list of claimed rights.

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementers or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003).  All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.  The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.  This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.




Cheshire, et al.             Standards Track                   [Page 30]

INTERNET-DRAFT               Link-Local IPv4                 3 June 2003


Open Issues

Open issues with this specification are tracked on the following web
site:

http://www.spybeam.org/issues.html

Expiration Date

This memo is filed as <draft-ietf-zeroconf-ipv4-linklocal-08.txt>,  and
expires November 22, 2003.








































Cheshire, et al.             Standards Track                   [Page 31]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/