[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-11.txt>        Microsoft Corporation
23 January 2004                                             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 (2004).  All Rights Reserved.

Abstract

   To participate in wide-area IP networking, a host needs to be
   configured with IP addresses for its interfaces, either manually by
   the user or automatically from a source on the network such as a DHCP
   server. Unfortunately, such address configuration information may not
   always be available. It is therefore beneficial for a host to be able
   to depend on a useful subset of IP networking functions even when no
   address configuration is available. This document describes how a
   host may automatically configure an interface with an IPv4 address
   within the 169.254/16 prefix that is valid for communication with
   other devices connected to the same physical (or logical) link.

   Link-Local IPv4 addresses are not suitable for communication with
   devices not directly connected to the same physical (or logical)
   link, and are only used where stable, routable addresses are not
   available (such as on ad hoc or isolated networks).  This document
   does not recommend that Link-Local IPv4 addresses and routable
   addresses be configured simultaneously on the same interface.




Cheshire, et al.             Standards Track                    [Page 1]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


Table of Contents

1.  Introduction..............................................    3
      1.1 Requirements .......................................    3
      1.2 Terminology ........................................    3
      1.3 Applicability.......................................    4
      1.4 Application Layer Protocol Considerations...........    5
      1.5 Autoconfiguration Issues ...........................    6
      1.6 Alternate Use Prohibition ..........................    6
      1.7 Multiple Addresses per Interface....................    7
      1.8 Multiple Interfaces.................................    7
      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..................   12
      2.7 Link-Local Packets Are Not Forwarded................   13
      2.8 Link-Local Packets are Local........................   14
      2.9 Higher-Layer Protocol Considerations................   14
     2.10 Privacy Concerns....................................   14
     2.11 Transition from Link-Local to Routable Address .....   15
     2.12 Interaction between DHCP4 and IPv4LL State
          Machines ...........................................   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......................   22
      6.3 Address Ambiguity...................................   22
7.  Router Considerations.....................................   22
8.  IANA Considerations.......................................   22
9.  Constants ................................................   22
10. References ...............................................   23
     10.1 Normative References ...............................   23
     10.2 Informative References .............................   23
Acknowledgments ..............................................   24
Authors' Addresses ...........................................   25
Appendix A - Prior Implementations............................   26
Intellectual Property Statement ..............................   29
Full Copyright Statement .....................................   30






Cheshire, et al.             Standards Track                    [Page 2]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


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:

   - when any host A from that set sends a packet to any other
    host B in that set, using unicast, multicast, or broadcast,



Cheshire, et al.             Standards Track                    [Page 3]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


    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 when
   they are the source of or intended destination of packets containing
   Link-Local IPv4 source or destination addresses.

   Wherever this document uses the term "sender IP address" or "target
   IP address" in the context of an ARP packet, it is referring to the
   fields of the ARP packet identified in the ARP specification [RFC826]
   as "ar$spa" (Sender Protocol Address) and "ar$tpa" (Target Protocol
   Address) respectively.  For the usage of ARP described in this
   document, each of these fields always contains an IP address.

   In this document, the term "ARP Probe" is used to refer to an ARP
   Request packet, broadcast on the local link, with an all-zero 'sender
   IP address'.  The 'sender hardware address' MUST contain the hardware
   address of the interface sending the packet.  The 'target hardware
   address' field is ignored and SHOULD be set to all zeroes.  The
   'target IP address' field MUST be set to the address being probed.

   In this document, the term "ARP Announcement" is used to refer to an
   ARP Request packet, broadcast on the local link, identical to the ARP
   probe described above, except that both the sender and target IP
   address fields contain the IP address being announced.

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



Cheshire, et al.             Standards Track                    [Page 4]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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

   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.



Cheshire, et al.             Standards Track                    [Page 5]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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.  This
   document does not recommend that Link-Local IPv4 addresses and
   routable addresses be configured simultaneously on the same
   interface.

   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].  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.   IPV4 addresses and names which can
   only be resolved on the local link SHOULD NOT be forwarded, they
   SHOULD only be sent when a Link-Local address is used as the source
   address.  This strong advice should hinder limited scope addresses
   and names from leaving the context in which they apply.

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

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.

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



Cheshire, et al.             Standards Track                    [Page 6]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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.

1.8.  Multiple Interfaces

   Additional considerations apply to hosts that support more than one
   active interface where one or more of these interfaces support Link-
   Local IPv4 address configuration.   These considerations are
   discussed in Section 3.






Cheshire, et al.             Standards Track                    [Page 7]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


1.9.  Communication with Routable Addresses

   There will be cases when devices with a configured Link-Local address
   will need to communicate with a device with a routable address
   configured on the same physical link, and vice versa.  The rules in
   Section 2.6  allow this communication.

   This allows, for example, a laptop computer with only a routable
   address to communicate with web servers world-wide using its
   globally-routable address while at the same time printing those web
   pages on a local printer that has only 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 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.




Cheshire, et al.             Standards Track                    [Page 8]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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 point
   of attachment may have changed or the network interface may have been
   inactive when a conflicting address was claimed.

   Were the host to immediately begin using a Link-Local IPv4 address
   which is already in use by another host, this would be disruptive to
   that other host.  Since it is possible that the host has changed its
   point of attachment, a routable address may be obtainable on the new
   network, and therefore it cannot be assumed that a Link-Local IPv4
   address is to be preferred.

   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.

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



Cheshire, et al.             Standards Track                    [Page 9]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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 PROBE_MIN to PROBE_MAX
   seconds, and should then send three probe packets, spaced randomly,
   PROBE_MIN to PROBE_MAX seconds apart.

   When ready to begin probing, the host should then wait for a random
   time interval selected uniformly in the range PROBE_MIN to PROBE_MAX
   seconds, and should then send NUM_PROBES probe packets, spaced
   randomly, PROBE_MIN to PROBE_MAX seconds apart.

   If during this period, from the beginning of the probing process
   until PROBE_MAX seconds after the last probe packet is sent, the host
   receives any ARP packet (Request *or* Reply) on the interface where
   the probe is being performed 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 the
   interfaces the host is attempting to configure, 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 MAX_COLLISIONS then the host
   MUST limit the rate at which it probes for new addresses to no more
   than one new address per RATE_LIMIT_INTERVAL.  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.

   If, by PROBE_MAX seconds after the transmission of the last ARP probe



Cheshire, et al.             Standards Track                   [Page 10]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   no conflicting ARP Reply or ARP probe has been received, then the
   host has successfully claimed the desired Link-Local IPv4 address.

2.3.  Shorter timeouts

   Network technologies may emerge for which shorter delays are
   appropriate than those required by this document. A subsequent IETF
   publication may be produced providing guidelines for different timer
   settings for PROBE_MIN and PROBE_MAX on those technologies.


2.4.  Announcing an Address

   The host MUST then announce its claimed address by broadcasting two
   ARP announcements, spaced PROBE_MAX 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) on an  interface where
   the 'sender IP address' is the IP address the host has  configured
   for that interface, but the 'sender hardware address' does not  match
   the hardware address of that interface, 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 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



Cheshire, et al.             Standards Track                   [Page 11]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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.

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.

   A multi-homed host needs to select an outgoing interface whether or



Cheshire, et al.             Standards Track                   [Page 12]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   not the destination is a Link-Local IPv4 address. Details of that
   process are beyond the scope of this specification. After selecting
   an interface, the multi-homed host should send packets involving
   Link-Local IPv4 addresses as specified in this document, as if the
   selected interface were the host's only interface. See Section 3 for
   further discussion of multi-homed hosts.

2.6.2.  Forwarding Rules

   Whichever interface is used, 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 can. If for any reason the host chooses to
   send the packet with a Link-Local IPv4 source address (e.g. no
   routable address is available on the selected interface), then it
   MUST 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.

   In the case of a device with a single interface and only a Link-Local
   IPv4 address, this requirement can be paraphrased as "ARP for
   everything".

   In many network stacks, achieving this "ARP for everything" behaviour
   may be as simple as having no primary IP router configured, having
   the primary IP router address configured to 0.0.0.0, or having the
   primary IP router address set to be the same as the host's own Link-
   Local IPv4 address.  For suggested behavior in multi-homed hosts, 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.




Cheshire, et al.             Standards Track                   [Page 13]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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.

   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.


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



Cheshire, et al.             Standards Track                   [Page 14]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


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


2.11.  Transition from Link-Local to Routable Address

   As discussed in Section 1.7, use of a routable address is preferred
   to assignment of a Link-Local IPv4 address. A Link-Local IPv4 address
   can be configured due to transient failures, such as incomplete link-
   layer authentication, spanning tree convergence issues, or because a
   DHCP server failed to respond to an initial query, or is inoperative
   for some time.

   Where a Link-Local IPv4 address is assigned due to a transient
   failure, experience has shown that five minutes (see Appendix A.2)
   may be too long an interval to wait prior to attempting to configure
   with DHCP.  This document does not specify a strategy for quickly
   recovering a routable address in situations where a Link-Local IPv4
   address is assigned due to a transient failure. In situations where
   many hosts are present on a single subnet, frequent attempts to
   contact the DHCP server could result in a heavy traffic load. Further
   discussion of this issue is provided in [DNAv4].


2.12.  Interaction between DHCPv4 client and IPv4ll state machines

   A device that implements both IPv4ll and a DHCPv4 client should not
   alter  the behavior of the DHCPv4 client to accommodate IPv4 Link-
   Local  configuration. In particular configuration of an IPv4 Link-
   Local address,  whether or not a DHCP server is currently responding,
   is not sufficient  reason to unconfigure a valid DHCP lease, to stop
   the DHCP client from  attempting to acquire a new IP address, to
   change DHCP timeouts or to  change the behaviour of the DHCP state
   machine in any other way.

   Several early implementations of IPv4 link-local have modified the
   DHCP  state machine in an attempt to make IPv4 link-local more
   reliable, and the  field experience we have gained from this has
   shown that it does not work  - reliability of DHCP service is
   significantly reduced.   If increased reliability of IPv4 link-local
   is desired, we recommend that the IPv4 link-local state machine track
   the DHCP client state machine and, in cases where it is not certain
   that the DHCP-assigned address is correct, the  IPv4ll state machine
   acquire an IPv4ll address without causing the DHCP  state machine to
   relinquish its address.

   Further discussion of this issue is provided in [DNAv4].






Cheshire, et al.             Standards Track                   [Page 15]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


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.

   It is possible to overcome these problems. One way is to expose scope
   information to applications such that they are always aware of what



Cheshire, et al.             Standards Track                   [Page 16]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   scope a peer is in. This way, the correct interface could be
   selected, and 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.

   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



Cheshire, et al.             Standards Track                   [Page 17]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


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




Cheshire, et al.             Standards Track                   [Page 18]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   In particular, ARP packets which appear to claim an address which is
   assigned to a specific interface, indicate conflict only if they are
   received on that interface and their hardware address is of some
   other interface.

   If a host has two interfaces on the same network, then claiming and
   defending on those interfaces must ensure that they end up with
   different addresses just as if they were on different hosts.

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.



Cheshire, et al.             Standards Track                   [Page 19]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   Note that sending periodic gratuitous ARPs in an attempt to detect
   these conflicts sooner is not necessary, wastes network bandwidth,
   and may actually be detrimental. For example, if the network links
   were joined only briefly, and were separated again before any new
   communication involving A or B were initiated, then the temporary
   conflict would have been benign and no forced reconfiguration would
   have been required. Triggering an unnecessary forced reconfiguration
   in this case would not serve any useful purpose. Hosts SHOULD NOT
   send periodic gratuitous ARPs.

5.  Security Considerations

   The use of IPv4 Link-Local Addresses may open a network host to new
   attacks. In particular, a host that previously did not have an IP
   address, and no IP stack running, was not susceptible to IP-based
   attacks. By configuring a working address, the host may now be
   vulnerable to IP-based attacks.

   The ARP protocol [RFC826] is insecure. A malicious host may send
   fraudulent ARP packets on the network, interfering with the correct
   operation of other hosts. For example, it is easy for a host to
   answer all ARP requests with replies giving its own hardware address,
   thereby claiming ownership of every address on the network.

   NOTE: 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 though use of Link-Local IPv4 addresses may reduce the



Cheshire, et al.             Standards Track                   [Page 20]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


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



Cheshire, et al.             Standards Track                   [Page 21]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


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

   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 is configured with a different address than the
   destination of the packet MUST NOT forward the packet.  This prevents
   forwarding of packets back onto the network segment from which they
   originated, or to any other segment.

8.  IANA Considerations

   The IANA has allocated the prefix 169.254/16 for the use described in
   this document. The first and last 256 addresses in this range
   (169.254.0.x and 169.254.255.x) are allocated by Standards Action, as
   defined in BCP 26. No other IANA services are required by this
   document.

9.  Constants

   The following timing constants are used in this protocol.

   PROBE_MIN              1 second
   PROBE_MAX              2 seconds
   NUM_PROBES             3
   MAX_COLLISIONS        10
   RATE_LIMIT_INTERVAL   60 seconds




Cheshire, et al.             Standards Track                   [Page 22]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


10.  References

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

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

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



Cheshire, et al.             Standards Track                   [Page 23]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


          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.

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

[DNAv4]   Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
          draft-ietf-dhc-dna-ipv4-01.txt, Internet draft (work in
          progress), September 2003.

[LLMNR]   Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast Name
          Resolution (LLMNR)", draft-ietf-dnsext-mdns-23.txt, Internet
          draft (work in progress), August 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,  Robert Elz, Peter Ford, Spencer
   Giacalone, Josh Graessley, Myron Hattig, Hugh Holbrook, Christian
   Huitema, Richard Johnson, Kim Yong-Woon, Mika Liljeberg, Rod Lopez,
   Keith Moore, Satish Mundra, Thomas Narten, Erik Nordmark, Philip Nye,
   Howard Ridenour, Daniel Senie, Dieter Siegmund, Valery Smyslov and
   Ryan Troll for their contributions.



















Cheshire, et al.             Standards Track                   [Page 24]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


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             23 January 2004


Appendix A - Prior Implementations

A.1. Apple Mac OS 8.x and 9.x.

   Mac OS chooses the IP address on a pseudo-random basis. The selected
   address is saved in persistent storage for continued use after
   reboot, when possible.

   Mac OS sends nine DHCPDISCOVER packets, with an interval of two
   seconds between packets. If no response is received from any of these
   requests (18 seconds), it will autoconfigure.

   Upon finding that a selected address is in use, Mac OS will select a
   new random address and try again, at a rate limited to no more than
   one attempt every two seconds.

   Autoconfigured Mac OS systems check for the presence of a DHCP server
   every five minutes.  If a DHCP server is found but Mac OS is not
   successful in obtaining a new lease, it keeps the existing
   autoconfigured IP address.  If Mac OS is successful at obtaining a
   new lease, it drops all existing connections without warning. This
   may cause users to lose sessions in progress.  Once a new lease is
   obtained, Mac OS will not allocate further connections using the
   autoconfigured IP address.

   Mac OS systems do not send packets addressed to a Link-Local address
   to the default gateway if one is present; these addresses are always
   resolved on the local segment.

   Mac OS systems by default send all outgoing unicast packets with a
   TTL of 255.  All multicast and broadcast packets are also sent with a
   TTL of 255 if they have a source address in the 169.254/16 prefix.

   Mac OS implements media sense where the hardware (and driver
   software) supports this.  As soon as network connectivity is
   detected, a DHCPDISCOVER will be sent on the interface.  This means
   that systems will immediately transition out of autoconfigured mode
   as soon as connectivity is restored.

A.2. Apple Mac OS X Version 10.2

   Mac OS X chooses the IP address on a pseudo-random basis. The
   selected address is saved in memory so that it can be re-used during
   subsequent autoconfiguration attempts during a single boot of the
   system.

   Autoconfiguration of a Link-Local address depends on the results of
   the DHCP process.  DHCP sends two packets, with timeouts of one and
   two seconds.  If no response is received (three seconds), it begins
   autoconfiguration.  DHCP continues sending packets in parallel for a
   total time of 60 seconds.



Cheshire, et al.             Standards Track                   [Page 26]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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.

   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.



Cheshire, et al.             Standards Track                   [Page 27]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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.  TTL configuration is performed by setting the
   Windows Registry Key
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\
   Parameters\DefaultTTL of type REG_DWORD to the appropriate value.
   However, this default TTL will apply to all packets.   While this
   facility could be used to set the default TTL to 255, it cannot be
   used to set the default TTL of 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 DHCP server included with Windows 98SE Internet Connection
   Sharing (ICS) (a NAT implementation) 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 IPv4 prefix off the local link.
   Windows 98SE ICS does not automatically route for the Link-Local IPv4
   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 IPv4 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



Cheshire, et al.             Standards Track                   [Page 28]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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.

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



Cheshire, et al.             Standards Track                   [Page 29]

INTERNET-DRAFT               Link-Local IPv4             23 January 2004


   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.

Open Issues

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

   http://www.drizzle.com/~aboba/ZEROCONF/issues.html

Expiration Date

This memo is filed as <draft-ietf-zeroconf-ipv4-linklocal-11.txt>,  and
expires July 24, 2004.
















Cheshire, et al.             Standards Track                   [Page 30]


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