[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

                                                         Stuart Cheshire
Document: draft-ietf-zeroconf-ipv4-linklocal-02.txt       Apple Computer
Expires 1st September 2001                                 Bernard Aboba
                                                               Microsoft
                                                          1st March 2001

            Dynamic Configuration of IPv4 Link-Local Addresses

               <draft-ietf-zeroconf-ipv4-linklocal-02.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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

   Distribution of this memo is unlimited.

Abstract

   As the Internet Protocol continues to increase in popularity as a
   global communication system, it becomes increasingly valuable to be
   able to use familiar IP tools such as ftp for local communication as
   well. For example, two people with laptop computers with built-in
   wireless Ethernet 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 [RFC 2131].

   This document describes a method by which a host may automatically
   configure an interface with an IPv4 address in the 169.254/16 range
   that is valid for link-local communication on that interface. This
   is especially valuable in environments where no other configuration
   mechanism is available.

   Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already
   implement versions of this functionality. This document standardizes
   this protocol and simplifies it in one important way -- in previous
   implementations, link-local addresses were only available after a
   host had tried and failed to contact a DHCP server. This standard
   removes that restriction, making link-local addresses available all
   the time, independent of DHCP.

Expires 1st September 2001           Cheshire & Aboba           [Page 1]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


1. Introduction

   As the Internet Protocol continues to increase in popularity as a
   global communication system, it becomes increasingly valuable to be
   able to use familiar IP tools such as ftp for local communication as
   well. For example, two people with laptop computers with built-in
   wireless Ethernet may meet and wish to transfer 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 [RFC 2131].

   This document describes a method by which a host may automatically
   configure an interface with an IPv4 address in the 169.254/16 range
   that is valid for link-local communication on that interface. This
   is especially valuable in environments where no other configuration
   mechanism is available. Allocation of link-local IPv6 addresses
   is described in [RFC 2462].

   Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already
   implement versions of this functionality. This document standardizes
   this protocol and simplifies it in one important way -- in previous
   implementations, link-local addresses were only available after a
   host had tried and failed to contact a DHCP server. This standard
   removes that restriction, making link-local addresses available all
   the time, independent of DHCP. Extremely simple devices may implement
   only IPv4 link-local addresses, without also being required to
   implement a DHCP client.

   Hosts and routers using addresses in the 169.254/16 range MUST follow
   the rules laid out in this document. This document will discuss
   claiming and defending addresses, maintaining link-local and routable
   addresses on the same interface, and multihoming issues.

   Note that addresses in the 169.254/16 range SHOULD NOT be configured
   manually or by a DHCP server, since doing so may cause a host to use
   an address in the 169.254/16 range without awareness of the special
   rules regarding duplicate detection and automatic configuration
   that pertain to addresses in this range. 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 ranges [RFC 1918], not
   the 169.254/16 range.









Expires 1st September 2001           Cheshire & Aboba           [Page 2]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


1.1. Conventions and Terminology Used in this Document

   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 [RFC 2119].

   This document uses the term "routable address" to refer to any
   unicast address outside the 169.254/16 range, including global
   addresses and private addresses such as Net 10/8 [RFC 1918].

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

   Wherever this document uses the term "ARP packet" or "ARP packets",
   the text should be taken to apply uniformly to ARP request and reply
   packets. Anywhere that the text does not apply equally to both kinds
   of ARP packet, this document explicitly states either "ARP request"
   or "ARP reply".


1.2. Table of Contents

   1.  Introduction..................................................2
   1.1 Conventions and Terminology Used in this Document.............3
   1.2 Table of Contents.............................................3
   1.3 Issues with Autoconfiguration.................................4
   1.4 Supporting Multiple Addresses per Interface...................4
   1.5 Supporting Multiple Interfaces................................4
   2.  IPv4 Link-Local Address Selection, Defense and Delivery.......5
   2.1 Selecting Link-Local Addresses................................5
   2.2 Claiming Link-Local Addresses.................................5
   2.3 Address Collision Detection and Address Defense...............7
   2.4 Source Address Selection......................................8
   2.5 Link-Local Addresses Are Not Forwarded........................8
   3.  Considerations for Multiple Interfaces........................9
   3.1 Example Illustrating Ambiguous Addressing....................11
   3.2 Example Illustrating Acceptable Address Re-Use...............12
   4.  Considerations for Joining of Previously Separate Networks...12
   5.  Security Considerations......................................13
   6.  Acknowledgements.............................................14
   7.  Copyright....................................................14
   8.  References...................................................14
   9.  Authors' Addresses...........................................15
   Appendix. Prior Implementations..................................16






Expires 1st September 2001           Cheshire & Aboba           [Page 3]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


1.3. Issues with Autoconfiguration

   Implementations of IPv4 link-local address autoconfiguration MUST
   expect address collisions, and MUST be prepared to handle them grace-
   fully 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 address, not just during some
   'startup phase' of 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.


1.4. Supporting Multiple Addresses per Interface

   IPv4 link-local addresses are independent from any other IPv4
   addresses that a host may have. Each interface on a host may have
   a link-local address in addition to zero or more other addresses
   configured by other means (e.g. manually or via a DHCP server).

   There are several reasons why it is beneficial for a host to maintain
   link-local addresses in addition to any other addresses it may have.
   For example, a DHCP server may appear on a network where hosts
   are already communicating using link-local addresses, and it is
   beneficial for those already-established link-local TCP connections
   to continue working even after the hosts have configured additional
   routable addresses assigned by the DHCP server.

   Another example is that there may be networks where not all of the
   hosts have externally configured addresses. For example, a user with
   a wireless home network may have a laptop computer and an IP printer.
   The laptop computer may have both a self-configured link-local
   address and a DHCP-configured global address. The printer, in
   contrast, may have only a link-local address, because the user does
   not want the printer to be globally addressable. In this case, the
   laptop computer would access pages on the World Wide Web using its
   globally-routable address to communicate with servers world-wide, but
   print those web pages using its link-local address to communicate
   with its local printer.


1.5. Supporting Multiple Interfaces

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




Expires 1st September 2001           Cheshire & Aboba           [Page 4]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


2. IPv4 Link-Local Address Selection, Defense and Delivery

   The following section explains the link-local address selection
   algorithm, how these addresses are defended and how IPv4 packets
   with link-local addresses are delivered.

   Windows 98 and Mac OS 8.5 hosts that already implement IPv4 address
   autoconfiguration 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 Selecting Link-Local Addresses

   When a host wishes to configure a link-local address, it selects an
   address using a random (or pseudo-random) number generator with a
   uniform distribution in the range from 169.254.1.0 to
   169.254.254.255. The IPv4 network 169.254/16 is registered with the
   IANA for this purpose. The first 256 and last 256 addresses in the
   169.254/16 network are reserved for future use and MUST NOT be
   selected by a host using this dynamic configuration mechanism.

   The pseudo-random number generation algorithm should be chosen so that
   different hosts do not generate the same sequence of numbers.
   Recommendations for pseudo-random number generators can be found in
   "Randomness Recommendations for Security" [RFC 1750]. If the host has
   access to persistent information that is different for each host,
   such as it's burned-in Ethernet hardware 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
   address each time it is booted, which can be convenient for debugging
   and other operational reasons. Seeding the pseudo-random number
   generator using the real-time clock is NOT suitable for this purpose,
   since a group of hosts that are all powered on at the same time might
   then all generate the same sequence.

2.2 Claiming Link-Local Addresses

   After it has selected an address, a host MUST test to see if the
   address is already in use before beginning to use it. On a network
   such as Ethernet that supports ARP, this test is done using ARP [RFC
   826] probes. On link-layer network technologies that do not support
   ARP there may be equivalent mechanisms for determining whether a
   particular IP address is currently in use, but these kinds of
   networks are not discussed in this document.

   A host probes to see if an address is already in use by broadcasting
   an ARP request for the desired address. The client MUST fill in its
   own interface hardware address as the sender's hardware address. The
   sender's IP address MUST be set to all zeroes, to avoid polluting ARP

Expires 1st September 2001           Cheshire & Aboba           [Page 5]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


   caches in other hosts on the same link in the case where the address
   turns out to already be in use by another host. The target hardware
   address is ignored and SHOULD be set to all zeroes. The target IP
   address MUST be set to the address being probed. An ARP request
   constructed this way with an all-zero sender address is referred to
   as an "ARP probe".

   The appropriate number of ARP probes and the interval between them is
   implementation-dependent. For Ethernet at 10Mb/s, 100Mb/s or 1Gb/s
   (henceforth referred to simply as 'Ethernet'), four probes with a
   two-second wait after each probe is recommended (making a total of
   eight seconds). If during this period the host receives any ARP
   packet 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 packet where the packet's 'target IP address' is the
   address being probed for, and the packet's 'sender hardware address'
   is not the hardware address of the interface the host is configuring,
   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
   by chance attempt to configure the same link-local 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 (on Ethernet) then the
   host MUST limit the rate at which it probes for new addresses to (on
   Ethernet) no more than one new address per second. 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.

   After successfully configuring a link-local address, a host on
   Ethernet SHOULD broadcast two gratuitous ARPs, spaced two seconds
   apart. A gratuitous ARP 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 IP address. The purpose of these
   gratuitous ARPs 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.

   Hosts that are equipped with persistent storage MAY, for each
   interface, record the IP address they have selected, and on the next
   boot 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.

Expires 1st September 2001           Cheshire & Aboba           [Page 6]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


2.3 Address Collision Detection and Address 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 where the 'sender IP address' is the host's
   own IP address, but the 'sender hardware address' that does not match
   any of the host's own interface addresses, then this is a conflicting
   ARP packet, 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 IP address as described above,
   or

   (b) If a host currently has active TCP connections or other reasons
   to prefer to keep the same IP address, and it has not seen any other
   conflicting ARP packets recently (for Ethernet, 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 gratuitous ARP request, 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
   Ethernet) then the host MUST immediately cease using this address and
   configure a new link-local IP address as described above. This is
   necessary to ensure that two hosts do not get stuck in an endless
   loop both 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 an 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 gratuitous ARP to defend the address mitigates the problem
   somewhat, by helping improve the chance that one of the two
   conflicting hosts may be able to retain its address.



Expires 1st September 2001           Cheshire & Aboba           [Page 7]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


   All ARP packets (replies as well as requests) that contain a link-
   local sender address SHOULD be sent using link-level broadcast
   instead of link-level unicast. This aids timely detection of
   duplicate addresses. An example illustrating how this helps is given
   in Section 4.

2.4 Source Address Selection

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

   If the destination address is in the 169.254/16 range, the host
   SHOULD use its link-local source address.

   If the destination address is a multicast address with link-local
   scope the host MAY use its link-local source address.

   If the destination address is a unicast address outside the
   169.254/16 range, or a multicast address with scope larger than link-
   local, the host SHOULD NOT use its link-local source address, and
   should instead use its appropriate routable interface address.

   In the case where two hosts on the same link each have both a link-
   local address and another address configured via some other means,
   it is usually preferable to use the configured addresses when
   establishing new communications. Those addresses are more likely to
   remain stable than link-local addresses, which may change over time,
   as described in Section 2.

2.5 Link-Local Addresses Are Not Forwarded

   An IPv4 datagram whose source and/or destination addresses is in the
   169.254/16 range MUST NOT be sent to any router for forwarding, and
   any network device receiving such a datagram MUST NOT forward it,
   regardless of the TTL in the IP header.

   This restriction also applies to multicast packets. IP datagrams with
   a link-local source address MUST NOT be forwarded off the local link
   even if they have a multicast destination address.

   Similar considerations apply at layers above IP. For example, DNS
   Resource Records containing link-local address SHOULD NOT be sent to
   hosts outside the link to which those link-local address apply.
   Automatically generated web pages SHOULD NOT contain links with
   embedded link-local addresses if those pages are viewable from hosts
   outside the local link where the addresses are valid. Since DNS
   treats Resource Record Sets [RFC 2181] as indivisible units

Expires 1st September 2001           Cheshire & Aboba           [Page 8]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


   (e.g. for generating DNS reply packets, signatures, etc.) this means
   that RRSets SHOULD only contain A records where all the addresses
   have the same scope. Link-local and routable addresses SHOULD NOT be
   mixed in a single set.

   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 range 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 many
   link-local-only devices will be extremely simple devices of the kind
   that currently use X10 [X10], USB [USB] or FireWire [IEEE 1394].
   The designers of these devices assume that they will communicate
   only with other local devices, and implement a degree of security
   appropriate for that expected environment. (For example, a typical
   USB mouse does not have a password, nor does it encrypt its mouse-
   movement data, and in most environments this is acceptable.)
   Any network gateway device that blindly forwards the contents of
   link-local IP packets off the local network (or vice-versa) exposes
   these link-local-only devices to a much greater degree of risk than
   their designers may have planned for.

   This does not mean that link-local devices are forbidden from
   communication outside the local link. IP hosts that implement both
   link-local and conventional routable IP addresses may still use
   their routable addresses without restriction as they do today.
   Extremely simple IP devices that implement only link-local addresses
   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 system
   could be controlled via a Web server on the local network, where the
   Web server uses cryptographic methods to verify the authority of the
   remote user, and then uses link-local communication on the local
   network to communicate commands to the heating system's thermostat.
   Alternatively, a remote host could use a secure tunnelling protocol
   to establish access to a 'virtual interface' on the local link, via
   which it could then send and receive 'virtual' link-local packets
   just like any other host directly connected to that link. It should
   be understood that this mediated communication is not mandatory; it
   is an option afforded to designers of very simple devices who wish to
   implement only link-local addresses and thereby simplify their
   security assumptions. 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 IP hosts on the same network.

Expires 1st September 2001           Cheshire & Aboba           [Page 9]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


3. Considerations for Multiple Interfaces

   A multi-homed host may elect to configure an IPv4 link-local address
   on only one of its active interfaces. In many situations this will be
   adequate. However, should a host wish to configure IPv4 link-local
   addresses on more than one of its active interfaces, there are some
   additional precautions it should take. Implementers who are not
   planning to support IPv4 link-local addresses simultaneously on
   multiple interfaces may skip this section.

   This section does not specify protocol requirements, but offers
   implementation advice which may aid deployment of link-local
   addresses on today's operating systems without requiring changes
   to application programming interfaces.

   A multi-homed host should ensure that all of its interfaces are
   configured with different link-local addresses. If the selection
   algorithm chooses an address that is already in use on one of the
   host's other interfaces, then the process should be repeated until a
   unique address is selected.

   A multi-homed host should also probe for, and defend, all of its
   link-local addresses on all of its active interfaces that are using
   link-local addresses. When bringing up a new interface, the host
   should first probe for all of its existing link-local addresses on
   that new interface. If any of the addresses are found to be in use
   already on the new link, then the interfaces in question must be
   reconfigured to select new unique link-local addresses. The host
   should then select a link-local address for the new interface, and
   probe on all of its active interfaces to verify that the address is
   unique. This uniqueness requirement exists to simplify host
   application software, which typically identifies connections using
   source and destination IP addresses, not interface names. Since
   link-local addresses are only unique per-link, hosts on different
   links could be using the same link-local address. By requiring
   uniqueness of source addresses on the multi-homed host, this ensures
   that TCP connections to hosts using the same link-local destination
   addresses on different links can be disambiguated by their different
   source addresses. Note that this also requires that the multi-homed
   host using link-local addresses on multiple interfaces MUST implement
   the "strong end system" model [RFC 1122] for packets going to
   link-local destination addresses, so that packets are only sent out
   from the interface that matches the source address in the packet.
   (The "weak end system" model may still be used for packets to other
   destinations.)

   When a multi-homed host receives an ARP packet on a particular
   interface with a sender IP address equal to one of the host's
   addresses, if the sender hardware address matches the hardware


Expires 1st September 2001           Cheshire & Aboba          [Page 10]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


   address of *any* of the host's active interfaces it should be
   silently discarded and not considered a collision. This is because a
   user of a multi-homed host with two Ethernet interfaces may connect
   both interfaces to the same Ethernet hub, in which case the two
   interfaces will see each other's packets, and if it did not check and
   realize that the apparently conflicting ARP packets were coming from
   itself the host could erroneously conclude that all its addresses
   were in conflict. Another common example is a host with both wired
   and wireless Ethernet interfaces, in an environment where a wireless
   gateway is available, but (perhaps unknown to the user) is bridged
   onto the same wired Ethernet.


3.1 Example Illustrating Ambiguous Addressing

   Figure 1 shows a network topology where host A has an interface on
   link X with link-local address P, and another interface on link Y
   with link-local address Q. If we allowed there to be another host, B,
   on link X that also has address Q, then although there are no conflicts
   strictly within the scope of either link, when host A sends a UDP
   packet from source address P to destination address Q, it is
   ambiguous whether A intends to talk to itself, or to host B. By
   ensuring that all of a host's link-local addresses are distinct not
   only from each other, but also from all addresses currently active on
   all links that the host is connected to, we remove this ambiguity.



                  |               |
                  |  P  -----  Q  |
                  |-----| A |-----|
                  |     -----     |
                  |               |
                  |               |
                 X|               |Y
                  |               |
                  |               |
        -----     |               |
        | B |-----|               |
        -----  Q  |               |
                  |               |


        Figure 1. Ambiguous Addressing







Expires 1st September 2001           Cheshire & Aboba          [Page 11]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


3.2 Example Illustrating Acceptable Address Re-Use

   Note that it is acceptable for different hosts on separate links to
   be using the same link-local address on their respective separate
   links. Figure 2 shows a network topology where host C on link X is
   using address R, while at the same time, host D on link Y is also
   using address R. This is entirely in keeping with the concept of
   link-local addresses. Link-local addresses are only unique amongst
   the member hosts of a single link. Hosts C and D are not on the same
   link, hence there is no requirement for them to have distinct
   addresses. Note that in this case, host A is still able to
   communicate with both hosts C and D, because a packet sent from
   source address P to destination address R travels on link X to host
   C, and a packet sent from source address Q to destination address R
   travels on link Y to host D. TCP connections are uniquely identified
   by the source and destination addresses and port numbers, not just by
   the destination address and port number alone. To support link-local
   addressing on multiple interfaces simultaneously, the network
   software API must allow applications to bind endpoints to a desired
   source address as well as specifying the desired destination address
   for a TCP connection. Networking implementations that only allow the
   destination address to be specified should limit themselves to
   configuring only one interface for link-local addressing.


                  |               |
                  |  P  -----  Q  |
                  |-----| A |-----|
                  |     -----     |
                  |               |
                 X|               |Y
                  |               |
        -----     |               |     -----
        | C |-----|               |-----| D |
        -----  R  |               |  R  -----
                  |               |

        Figure 2. Acceptable Address Re-Use


4. Considerations for Joining of Previously Separate Networks

   Hosts on disjoint network links may unknowingly configure the same
   link-local addresses. 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 a duplicate address.


Expires 1st September 2001           Cheshire & Aboba          [Page 12]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


   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 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 there is a greater chance of
   collision, but large networks are not expected to rely heavily on
   link-local addresses for normal communication. Large networks are
   better managed by using existing mechanisms such as DHCP servers to
   allocate addresses.

   Sending ARP replies that have 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 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 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 this functionality 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 [RFC 826] 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 responses giving its own hardware
   address, thereby claiming ownership of every address on the network.

Expires 1st September 2001           Cheshire & Aboba          [Page 13]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


6. Acknowledgements

   We'd like to thank (in alphabetical order) Donald Eastlake 3rd, Peter
   Ford, Erik Guttman, Myron Hattig, Hugh Holbrook, Richard Johnson,
   Satish Mundra, Thomas Narten, Daniel Senie, Valery Smyslov and Ryan
   Troll for their contributions.


7. Copyright

   Copyright (C) The Internet Society 8th March 2000.
   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.


8. References

   [IEEE 1394]IEEE Std 1394-1995,
              Standard for a High Performance Serial Bus

   [RFC 826]  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.




Expires 1st September 2001           Cheshire & Aboba          [Page 14]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


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

   [RFC 1750] D. Eastlake 3rd, S. Crocker and J. Schiller, "Randomness
              Recommendations for Security", RFC 1750, December 1994.

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

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

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

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

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

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

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


9. 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
   USA

   Phone: +1 425 936 6605
   Fax: +1 425 936 7329
   EMail: bernarda@microsoft.com


Expires 1st September 2001           Cheshire & Aboba          [Page 15]

Internet Draft         IPv4 Link-Local Addresses          1st March 2001


Appendix. Prior Implementations

   This standard builds upon experience gained implementing link-local
   addresses in Windows 98 and Mac OS 8.5.

   These implementations had a number of drawbacks.

   These operating systems did not support more than one active IPv4
   address at a time. For this reason, these implementations would only
   configure a link-local address after attempting to contact a DHCP
   server and failing. This meant link-local addresses were only
   available on systems configured to use DHCP, and on those only if
   DHCP failed.

   Because they only configure a link-local address after DHCP has
   failed, on isolated networks, boot time is delayed by the time it
   takes the DHCP client to time-out, which was 24 seconds for Windows
   and 15 seconds for Mac OS.

   Having failed to contact a DHCP server, these implementations retry
   once every five minutes. If the failure to contact a DHCP server was
   a transient problem such as a loose Ethernet cable, after correcting
   the error, it could take up to five minutes for the system to
   reconfigure with a server-assigned address.

   Because these operating systems did not support more than one active
   IPv4 address at a time, when they reconfigured with a server-assigned
   address, the self-configured link-local address would be lost. Any
   open TCP connections would be broken without warning, possibly
   causing user data loss, and the ability to communicate with simple
   devices that implement only link-local addressing would be lost.




















Expires 1st September 2001           Cheshire & Aboba          [Page 16]


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