[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-01.txt       Apple Computer
Expires 24th May 2001                                 24th November 2000

            Dynamic Configuration of IPv4 link-local addresses

               <draft-ietf-zeroconf-ipv4-linklocal-01.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 [RFC 2131] server.

   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.

   Autoconfiguration for IPv4 using 169.254/16 link-local addresses
   has been implemented and shipped for years now for Macintosh and
   Windows operating systems.  This document defines the protocol
   implemented by this important installed base.  This document goes
   further, however, and specifies how link-local configuration should
   be used by hosts that support multi-homing (more than one active
   interface and/or more than one active address per interface).



Expires 24th May 2001          Cheshire                         [Page 1]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000


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

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

   Autoconfiguration for IPv4 using 169.254/16 link-local addresses
   has been implemented and shipped for years now for Macintosh and
   Windows operating systems.  This document defines the protocol
   implemented by this important installed base.  This document goes
   further, however, and specifies how link-local configuration should
   be used by hosts that support multi-homing (more than one active
   interface and/or more than one active address per interface).

   Hosts 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, multihoming issues, and maintaining addresses of
   link-local and global scope for the same interface. Note that
   addresses in the 169.254/16 range SHOULD NOT be configured manually
   or by a DHCP server, since doing so may cause the host to use an
   address in the 169.254/16 range without awareness of the special
   rules regarding duplicate detection and automatic configuration which
   pertain to addresses in this range.

1.1. Conventions Used in the 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 avoids using the term 'global address' since the
   considerations that apply to link-local addresses in comparison to
   global addresses also apply equally in comparison to other kinds of
   addresses, such as Net 10/8 addresses, which are not global [RFC
   1918]. This document uses the slightly awkward but more accurate term
   'non-link-local address' when referring to any IPv4 address that has
   larger scope than link-local.


Expires 24th May 2001          Cheshire                         [Page 2]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000


1.2. Table of Contents

   1.  Introduction..................................................2
   1.1 Terminology...................................................2
   1.2 Table of Contents.............................................3
   1.3 Issues with Autoconfiguration.................................3
   1.4 Supporting Multiple Addresses per Interface...................3
   1.5 Supporting Multiple Interfaces................................3
   2.  IPv4 Link-Local Address Selection, Defense and Delivery.......4
   2.1 Selecting Link-Local Addresses................................4
   2.2 Claiming Link-Local Addresses.................................4
   2.3 Address Collision Detection and Address Defense...............5
   2.4 Link-Local Addresses Are Not Forwarded........................6
   3.  Considerations for Single-Homed Hosts.........................7
   4.  Considerations for Multiple Addresses per Interface...........7
   5.  Considerations for Multiple Interfaces........................8
   6.  Considerations for Joining of Previously Separate Networks...11
   7.  Security Considerations......................................11
   8.  Acknowledgements.............................................11
   9.  Copyright....................................................12
   10. References...................................................12
   11. Author's Address.............................................13

1.3. Issues with Autoconfiguration

   Implementations of IPv4 link-local address autoconfiguration MUST
   expect address collisions, and MUST be prepared to handle them
   gracefully by being prepared to automatically select 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 6.

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).
   The motivation for this new capability as well as its implications
   are discussed in Section 4.

1.5. Supporting Multiple Interfaces

   Hosts which 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 5.

Expires 24th May 2001          Cheshire                         [Page 3]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000

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.

   The rules presented in this section are compatible with the
   protocol used by hosts which already implement IPv4 address
   autoconfiguration.

2.1 Selecting Link-Local Addresses

   When a host wishes to configure a link-local address, it selects an
   address pseudo-randomly, uniformly distributed in the range
   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 this network are reserved for future use and SHOULD NOT
   be selected by a host using this dynamic configuration mechanism.

   The pseudo-random number generator 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, the 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.

   The host tests to see if the address is already in use by
   broadcasting an ARP request for the desired address. The client MUST
   fill in its own hardware address as the sender's hardware address,
   and all zeroes as the sender's IP address, to avoid polluting ARP
   caches in other hosts on the same link in the case where the address
   turns out to already be in use by another host. This ARP request with
   a sender IP address of all zeroes is referred to as an "ARP probe".

Expires 24th May 2001          Cheshire                         [Page 4]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000


   The appropriate number of ARP probes and the interval between them
   may be implementation-dependent. For Ethernet at 10Mb/s, 100Mb/s or
   1Gb/s (henceforth referred to simply as 'Ethernet'), four probes with
   a two-second interval is recommended. If the host receives an ARP
   response indicating that the address is currently in use, then the
   host should select a new pseudo-random address and repeat the process.

   While waiting for a possible response to this request, the client
   MUST also listen for other ARP probes for the same address
   originating from other hosts. This will occur if two (or more) hosts
   are by chance attempting to configure the same link-local address at
   the same time. If the client receives a response to the ARP request,
   or sees another ARP probe for the same IP address with another host's
   hardware address, it MUST consider the IP address as being in use,
   and move on.

   A host SHOULD keep a counter of the number of address collisions it
   has experienced in the process of trying to acquire an address, and
   if the count becomes too high it should cease attempting to acquire
   an address. This is to prevent infinite loops in pathological failure
   cases. On Ethernet, fifty consecutive failed attempts should be
   considered "too high".

   After successfully configuring a link-local address, a host on
   Ethernet SHOULD send two gratuitous ARPs, spaced two seconds apart,
   this time filling in the sender IP address. The purpose of these
   gratuitous ARPs is to make sure that other hosts on the net 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 on an isolated IPv4 network 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 which arise.

2.3 Address Collision Detection and Address Defense

   Address collision detection is not limited to the address selection
   phase, when the host is sending ARP probes and listening for replies.
   Address collision detection is an ongoing process that is in effect
   for as long as the host is using a link-local IPv4 address. At any
   time, if a host receives an ARP packet with its own IP address given
   as the sender IP address, but a sender hardware address that does not
   match any of its own interface addresses, then the host MUST treat
   this as an address collision and MUST respond as described in either
   (a) or (b) below:

Expires 24th May 2001          Cheshire                         [Page 5]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000

   (a) Upon detecting an address conflict, 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 once, by
   recording the time that the conflicting ARP packet was received, and
   then broadcasting one single gratuitous ARP, giving its own IP and
   hardware addresses as the source addresses of the ARP. However, if
   another conflicting ARP packet is received within a short time after
   that (ten seconds for Ethernet) then the host MUST immediately
   configure a new link-local IP address as described above.

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

   After successfully configuring a link-local address, all subsequent
   ARP packets (replies as well as requests) containing a link-local
   source address SHOULD be sent using link-level broadcast instead of
   link-level unicast. This is important to enable timely detection of
   duplicate addresses, as described above. As an alternative, a host
   which cannot send broadcast ARP replies SHOULD send a unicast ARP
   reply but then neglect to follow the instructions in RFC 826 about
   recording sender information from received ARP requests. This means
   that, having failed to record the sender information, the host is
   likely to send a broadcast ARP request of its own shortly later,
   which allows another host using the same IP address to detect the
   conflict and respond to it.

2.4 Link-Local Addresses Are Not Forwarded

   IPv4 datagrams whose source or destination addresses are in the
   169.254/16 range MUST NOT be sent to any router for forwarding, and
   any network device receiving such datagrams MUST NOT forward them.

Expires 24th May 2001          Cheshire                         [Page 6]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000


   This restriction also applies to multicast packets. IP datagrams with
   a multicast destination address and a link-local source address
   SHOULD NOT be forwarded off the local link. 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. Similarly,
   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 (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 non-link-local addresses SHOULD NOT be
   mixed in a single set.

   Network Address Translation technologies [NAT-ARCH] [NAT-PROT] may be
   used to circumvent the non-forwarding rule, with the usual caveats:
   all occurrences of local-scoped addresses must be correctly rewritten
   with their appropriate equivalent larger-scoped addresses, including
   addresses in DNS packets, addresses embedded in Web links, etc. This
   document does not endorse the use of NAT [NAT-ARCH] [NAT-PROT], but
   neither does it attempt to prohibit it.

   The corollary of the non-forwarding rule is 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.

3. Considerations for Single-Homed Hosts

   Some operating systems do not support a host having more than one
   active IPv4 address at a time. These hosts may have one externally
   configured (e.g. manual or DHCP) IP address, or one self-configured
   link-local address, but not both at the same time.

   These hosts should only configure a link-local address on their
   interface when other means of configuring an address have failed. For
   example, if a host is set to obtain its address via DHCP, then after
   attempting to contact a DHCP server for a reasonable period of time
   and failing, it may elect instead to configure a link-local address.
   For a host on Ethernet, sending four DHCP DISCOVER packets over a
   period of 15-30 seconds would qualify as "attempting to contact a
   DHCP server for a reasonable period of time."

   Having elected to configure a link-local address, these hosts MUST
   continue attempting to contact a DHCP server by sending periodic DHCP


Expires 24th May 2001          Cheshire                         [Page 7]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000


   DISCOVER packets. The host has no way of knowing whether it is on a
   network with no DHCP service, or on a network where the DHCP server
   was temporarily inaccessible or unresponsive. For a host on Ethernet,
   attempting to contact a DHCP server once every five minutes is
   reasonable. If the host receives a DHCP OFFER in response to one of
   its periodic DHCP DISCOVER packets, and successfully completes a DHCP
   DISCOVER/OFFER/REQUEST/ACK packet exchange with the server, then a
   host which is incapable of supporting more than one IP address at a
   time should immediately cease using its link-local address and
   reconfigure its interface using the information received from the
   DHCP server.

   Immediate cessation of use of the link-local address may break active
   TCP connections with other link-local peers, possibly causing user
   data loss. This is why it is extremely beneficial for a host, even
   if it cannot support true multi-homing, to at least support multiple
   IP addresses on a single physical interface, so that it may maintain
   its link-local address in addition to other addresses configured
   by other means such as DHCP.

   All IPv6 hosts are required to be able to support multiple IPv6
   addresses per interface.

4. Considerations for Multiple Addresses per Interface

   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
   larger-scoped 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.

   A host which has a both a link-local and one or more non-link-local
   address assigned to a single interface requires additional
   capabilities in order to select which source address to use to
   communicate with a given destination address.


Expires 24th May 2001          Cheshire                         [Page 8]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000


   In the case where two hosts on the same link have both link-local
   addresses and non-link-local addresses, they SHOULD prefer the
   larger-scoped addresses when establishing new communications (e.g.
   TCP connections) because their non-link-local addresses are likely to
   remain stable whereas their link-local addresses could change over
   time, as described in Section 2.

   A host which has both a link-local address and another address with
   larger scope, SHOULD NOT establish communications from a link-local
   source address to a non-link-local destination address, or vice
   versa. However, a host which has only one or other kind of address
   MAY choose to use that address for communication with the other kind
   of address on the same link. Thus a host with only a link-local
   address wishing to send a packet to another host on the same link
   with only a non-link-local address MAY use ARP on the link to find
   the hardware address and send the packet directly to the destination
   host. (This is equivalent to saying that a host with only a
   link-local address should have a default route entry indicating that
   all hosts are directly reachable through its IP interface, without
   going through any gateway.) Likewise, a host with only a
   non-link-local address wishing to send a packet to a link-local
   destination address MAY use ARP and send the packet directly to the
   destination host on that link. (This is equivalent to saying that a
   host with only a non-link-local address should also have a route
   entry indicating that net 169.254/16 is directly reachable through
   its IP interface, without going through any gateway.) This allows a
   host which has only a link-local address to communicate with another
   host on the same link which has only a non-link-local address. This
   also allows vendors of Network Address Translation gateways to
   implement a gateway which issues proxy ARP replies for all non-local
   addresses, and then appropriately translates all IP packets it
   consequently receives to eliminate link-local source addresses before
   forwarding them to the larger network. This document does not endorse
   the use of NAT [NAT-ARCH] [NAT-PROT], but neither does it attempt to
   prohibit it.

5. 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 on more than one
   interface at a time may skip this section.

   A multi-homed host MUST NOT forward IP datagrams it receives that
   have source or destination addresses in the 169.254/16 range. A
   multi-homed host should ensure that all of its links are configured
   with different link-local addresses. If the pseudo-random number

Expires 24th May 2001          Cheshire                         [Page 9]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000


   generator selects an address which is already in use on one of the
   host's other interfaces, then another address should be 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 is in order 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
   destination addresses.)

   When a multi-homed host receives an ARP packet on a particular
   interface with a source IP address equal to one of the host's
   addresses, it should be silently discarded and not considered a
   collision if the source hardware address matches the hardware address
   of *any* of the host's active interfaces. 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 the host could erroneously
   conclude that all its addresses were in conflict if it did not check
   and realize that the apparently conflicting ARP packets were coming
   from itself. 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.

   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 which also has address Q, then 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

Expires 24th May 2001          Cheshire                        [Page 10]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000


   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

   Note that it is acceptable for different hosts on different 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 addressing

Expires 24th May 2001          Cheshire                        [Page 11]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000


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

   If a host receives an ARP packet with its own IP address given as the
   sender IP address, but a sender hardware address that is not one of
   its own, then the host must treat this as an address collision and
   MUST handle it as described in Section 2.3 above.

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

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

8. Acknowledgements

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




Expires 24th May 2001          Cheshire                        [Page 12]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000


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

10. References

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

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

Expires 24th May 2001          Cheshire                        [Page 13]

Internet Draft         IPv4 Link-Local Addresses        8th October 2000

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

   [NAT-ARCH] Hain, T., "Architectural Implications of NAT", Work in
              Progress.

   [NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications
              with the IP Network Address Translator (NAT)", Work in
              Progress.

11. Author's Address

   Stuart Cheshire
   Apple Computer, Inc.
   1 Infinite Loop
   Cupertino
   California 95014
   USA

   Phone: +1 408 974 3207
   EMail: rfc@stuartcheshire.org




























Expires 24th May 2001          Cheshire                        [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/