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

Versions: 00 01 02 03 04 05 06 RFC 5227

Document: draft-cheshire-ipv4-acd-04.txt                 Stuart Cheshire
Category: Standards Track                                 Apple Computer
Updates: 826                                              11th July 2005
Expires 11th January 2006

                    IPv4 Address Conflict Detection
                    <draft-cheshire-ipv4-acd-04.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
   For the purposes of this document, the term "BCP 79" refers
   exclusively to RFC 3979, "Intellectual Property Rights in IETF
   Technology", published March 2005.

   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/1id-abstracts.html

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


Abstract

   When two hosts on the same link attempt to use the same IPv4 address
   at the same time (except in rare special cases where this has been
   arranged by prior coordination) problems ensue for one or both hosts.
   This document describes (i) a simple precaution that a host can take
   in advance to help prevent this misconfiguration from happening, and
   (ii) if this misconfiguration does occur, a simple mechanism by which
   a host can passively detect after-the-fact that it has happened, so
   that the host or administrator may respond to rectify the problem.










Expires 11th January 2006             Cheshire                  [Page 1]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


1. Introduction

   Historically, accidentally configuring two Internet hosts with the
   same IP address has often been an annoying and hard-to-diagnose
   problem.

   This is unfortunate, because the existing ARP protocol provides
   an easy way for a host to detect this kind of misconfiguration and
   report it to the user.  The DHCP specification [RFC2131] briefly
   mentions the role of ARP in detecting misconfiguration, as
   illustrated in the following three excerpts from RFC 2131:

    o the client SHOULD probe the newly received address,
      e.g., with ARP.

    o The client SHOULD perform a final check on the parameters
      (e.g., ARP for allocated network address)

    o If the client detects that the address is already in use
      (e.g., through the use of ARP), the client MUST send
      a DHCPDECLINE message to the server

   Unfortunately, the DHCP specification does not give any guidance to
   implementers concerning the number of ARP packets to send, the
   interval between packets, the total time to wait before concluding
   that an address may safely be used, or indeed even which kinds of
   packets a host should be listening for, in order to make this
   determination.  It leaves unspecified the action a host should take
   if, after concluding that an address may safely be used, it
   subsequently discovers that it was wrong.  It also fails to specify
   what precautions a DHCP client should take to guard against
   pathological failure cases, such as DHCP server that repeatedly
   OFFERs the same address, even though it has been DECLINEd multiple
   times.

   The authors of the DHCP specification may have have been justified
   in thinking at the time that the answers to these questions seemed
   too simple, obvious and straightforward to be worth mentioning, but
   unfortunately this left some of the burden of protocol design to each
   individual implementer.  This document seeks to remedy this omission
   by clearly specifying the required actions for:

   1. Determining whether use of an address is likely to lead to an
      addressing conflict.  This includes (a) the case where the address
      is already actively in use by another host on the same link, and
      (b) the case where two hosts are inadvertently about to begin
      using the same address, and both are simultaneously in the process
      of probing to determine whether the address may safely be used.
      (Section 2.1.)


Expires 11th January 2006             Cheshire                  [Page 2]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


   2. Subsequent passive detection that another host on the network is
      inadvertently using the same address.  Even if all hosts observe
      precautions to avoid using an address that is already in use,
      conflicts can still occur if two hosts are out of communication at
      the time of initial interface configuration.  This could occur
      with wireless network interfaces if the hosts are temporarily out
      of range, or with Ethernet interfaces if the link between two
      Ethernet hubs is not functioning at the time of address
      configuration.  A well-designed host will handle not only
      conflicts detected during interface configuration, but also
      conflicts detected later, for the entire duration of the time
      that the host is using the address. (Section 2.4.)

   3. Rate-limiting of address acquisition attempts in the case of
      an excessive number of repeated conflicts. (Section 2.1.)

   The utility of IPv4 Address Conflict Detection (ADC) is not limited
   to DHCP clients.  No matter how an address was configured, whether
   via manual entry by a human user, via information received from a
   DHCP server, or via any other source of configuration information,
   detecting conflicts is useful.  Upon detecting a conflict, the
   configuring agent should be notified of the error.  In the case where
   the configuring agent is a human user, that notification may take the
   form of an error message on a screen, an SNMP trap, or an error
   message sent via pager.  In the case of a DHCP server, that
   notification takes the form of a DHCP DECLINE message sent to the
   server.  In the case of configuration by some other kind of software,
   that notification takes the form of an error indication to the
   software in question, to inform it that the address it selected is
   in conflict with some other host on the network.  The configuring
   software may choose to cease network operation, or it may
   automatically select a new address so that the host may re-establish
   IP connectivity as soon as possible.

   Allocation of IPv4 Link-Local Addresses [RFC3927] can be thought of
   as a special-case of this mechanism, where the configuring agent is
   a pseudo-random number generator, and the action it takes upon being
   notified of a conflict is to pick a different random number and try
   again.  In fact, this is exactly how IPv4 Link-Local Addressing was
   implemented in Mac OS 9 back in 1998.  If the DHCP client failed to
   get a response from any DHCP server, it would simply make up a fake
   response containing a random 169.254.x.x address.  If the ARP module
   reported a conflict for that address, then the DHCP client would try
   again, making up a new random 169.254.x.x address as many times as
   was necessary until it succeeded.  Implementing ACD as a standard
   feature of the networking stack has the side-effect that it means
   that half the work for IPv4 Link-Local Addressing is already done.




Expires 11th January 2006             Cheshire                  [Page 3]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


1.1. Conventions and Terminology Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC2119].

   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 IPv4 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 '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
   Probe" conveys both a question ("Is anyone using this address?")
   and an implied statement ("This is the address I intend to use.").

   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.
   It conveys a stronger statement than an "ARP Probe", namely,
   "This is the address I am now using."

   The following timing constants are used in this protocol; they are
   not intended to be user-configurable.  These constants are referenced
   in Section 2, which describes the operation of the protocol in
   detail.

   PROBE_WAIT           1 second   (initial random delay)
   PROBE_NUM            3          (number of probe packets)
   PROBE_MIN            1 second   (minimum delay until repeated probe)
   PROBE_MAX            2 seconds  (maximum delay until repeated probe)
   ANNOUNCE_WAIT        2 seconds  (delay before announcing)
   ANNOUNCE_NUM         2          (number of announcement packets)
   ANNOUNCE_INTERVAL    2 seconds  (time between announcement packets)
   MAX_CONFLICTS       10          (max conflicts before rate limiting)
   RATE_LIMIT_INTERVAL 60 seconds  (delay between successive attempts)
   DEFEND_INTERVAL     10 seconds  (minimum interval between defensive
                                    ARPs).


Expires 11th January 2006             Cheshire                  [Page 4]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


1.2 Relationship to RFC 826

   This document does not modify any of the protocol rules in RFC 826.
   It does not modify the packet format, or the meaning of any
   of the fields.  The existing rules for "Packet Generation" and
   "Packet Reception" still apply exactly as specified in RFC 826.

   This document expands on RFC 826 by specifying:

   (1) that a specific ARP Request should be generated when an interface
       is configured, to discover if the address is already in use, and

   (2) an additional trivial test that should be performed on each
       received ARP packet, to facilitate passive ongoing conflict
       detection.  This additional test creates no additional packet
       overhead on the network (no additional packets are sent) and
       negligible additional CPU burden on hosts, since every host
       implementing ARP is *already* required to process every received
       ARP packet according to the "Packet Reception" rules specified in
       RFC 826.  These rules already include checking to see if the
       sender IP address of the ARP packet appears in any of the entries
       in the host's ARP cache; the additional test is simply to check
       to see if the sender IP address is the host's *own* IP address,
       potentially as little as a single additional machine instruction
       on many architectures.

   As already specified in RFC 826, an ARP Request packet serves two
   functions, an assertion and a question:

   * Assertion:
     The fields "ar$sha" (Sender Hardware Address) and "ar$spa" (Sender
     Protocol Address) together serve as an assertion of a fact, that
     the stated Protocol Address is mapped to the stated Hardware
     Address.

   * Question:
     The fields "ar$tha" (Target Hardware Address, zero) and "ar$tpa"
     (Target Protocol Address) serve as a question, asking, for the
     stated Protocol Address, to which Hardware Address it is mapped.

   This document clarifies what it means to have one without the other.


1.2.1 Broadcast Replies

   In some applications of IPv4 Address Conflict Detection (ACD), it
   may be advantageous to deliver ARP Replies using broadcast instead of
   unicast because this allows address conflicts to be detected sooner
   than might otherwise happen.  For example, "Dynamic Configuration of


Expires 11th January 2006             Cheshire                  [Page 5]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


   IPv4 Link-Local Addresses" [RFC3927] uses ACD exactly as specified
   here, but additionally specifies that ARP Replies should be sent
   using broadcast, because in that context the trade-off of increased
   broadcast traffic in exchange for improved reliability and
   fault-tolerance was deemed to be an appropriate one. There may be
   other future specifications where the same trade-off is appropriate.

   RFC 826 implies that replies to ARP Requests are usually delivered
   using unicast, but it is also acceptable to deliver ARP Replies using
   broadcast.  The "Packet Reception" rules in RFC 826 specify that the
   content of the "ar$spa" field should be processed *before* examining
   the "ar$op" field, so any host that correctly implements the Packet
   Reception algorithm specified in RFC 826 will correctly handle ARP
   Replies delivered via link-layer broadcast.


1.3. Applicability

   This specification applies to all IEEE 802 Local Area Networks (LANs)
   [802], including Ethernet [802.3], Token-Ring [802.5] and IEEE 802.11
   wireless LANs [802.11], as well as to other link-layer technologies
   that operate at data rates of at least 1 Mbps, have a round-trip
   latency of at most one second, and use ARP [RFC826] to map from IP
   addresses to link-layer hardware addresses.  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 will still work correctly with
   this protocol, but more often may have to handle late conflicts
   detected after the Probing phase has completed.  On these kinds
   of link, it may be desirable to specify different values for the
   following parameters:

   (a) PROBE_NUM, PROBE_MIN, and PROBE_MAX, the number of, and interval
       between, ARP probes, explained in Section 2.1.1.

   (b) ANNOUNCE_NUM and ANNOUNCE_INTERVAL, the number of, and interval
       between, ARP announcements, explained in Section 2.3.

   (c) RATE_LIMIT_INTERVAL and MAX_CONFLICTS, controlling the maximum
       rate at which address claiming may be attempted, explained in
       Section 2.1.1.

   (d) DEFEND_INTERVAL, the time interval between conflicting ARPs below
       which a host MUST NOT attempt to defend its address, explained in
       Section 2.4.




Expires 11th January 2006             Cheshire                  [Page 6]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


   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, implementing Address Conflict Detection
   for such networks is outside the scope of this document.

   For the protocol specified in this document to be effective,
   it is not necessary that every host on the link implements it.
   For a given host implementing this specification to be protected
   against accidental address conflicts, all that is required is that
   the peers on the same link correctly implement the ARP protocol as
   given in RFC 826.  To be specific, when a peer host receives an ARP
   Request where the Target Protocol Address of the ARP Request matches
   (one of) that host's IP address(es) configured on that interface,
   then as long as it properly responds with a correctly-formatted ARP
   Reply, the querying host will be able to detect that the address is
   already in use.

   The specifications in this document allow hosts to detect conflicts
   between two hosts using the same address on the same physical link.
   ACD does not detect conflicts between two hosts using the same
   address on different physical links, and indeed it should not.
   For example, the address 10.0.0.1 [RFC1918] is in use by countless
   devices on countless private networks throughout the world, and this
   is not a conflict, because they are on different links.  It would
   only be a conflict if two such devices were to be connected to the
   same link, and when this happens (as it sometimes does), this is a
   perfect example of a situation where ACD is extremely useful to
   detect and report (and/or automatically correct) this error.

   For the purposes of this document, 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, 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.



Expires 11th January 2006             Cheshire                  [Page 7]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


2. Address Probing, Announcing, Conflict Detection and Defense

   This section describes initial probing to safely determine whether an
   address is already in use, announcing the chosen address, ongoing
   conflict checking, and optional use of broadcast ARP Replies to
   provide faster conflict detection.


2.1 Probing an Address

   Before beginning to use an IPv4 address (whether received from manual
   configuration, DHCP, or some other means), a host implementing this
   specification MUST test to see if the address is already in use, by
   broadcasting ARP Probe packets.  This also applies when when a
   network interface transitions from an inactive to an active state,
   when a computer awakes from sleep, when a link-state change signals
   that an Ethernet cable has been connected, when an 802.11 wireless
   interface associates with a new base station, or any other change in
   connectivity where a host becomes actively connected to a logical
   link.

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

2.1.1.  Probe Details

   A host probes to see if an address is already in use by broadcasting
   an ARP Request for the desired address.  The client MUST fill in the
   'sender hardware address' field of the ARP Request with the hardware
   address of the interface through which it is sending the packet.  The
   'sender IP address' field MUST be set to all zeroes, to avoid
   polluting ARP caches in other hosts on the same link in the case
   where the address turns out to be already in use by another host.
   The 'target hardware address' field is ignored and SHOULD be set to
   all zeroes.  The 'target IP address' field MUST be set to the address
   being probed.  An ARP Request constructed this way with an all-zero
   'sender IP address' is referred to as an "ARP Probe".

   When ready to begin probing, the host should then wait for a random
   time interval selected uniformly in the range zero to PROBE_WAIT
   seconds, and should then send PROBE_NUM probe packets, each of these
   probe packets spaced randomly, PROBE_MIN to PROBE_MAX seconds apart.
   This initial random delay helps ensure that a large number of hosts
   powered on at the same time do not all send their initial probe
   packets simultaneously.




Expires 11th January 2006             Cheshire                  [Page 8]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


   If during this period, from the beginning of the probing process
   until ANNOUNCE_WAIT 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 should indicate
   to the configuring agent (human operator, DHCP server, etc.) that the
   proposed address is not acceptable.

   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 interface the host is attempting to configure, then
   the host MUST similarly treat this as an address conflict and signal
   an error to the configuring agent as above.  This can occur if two
   (or more) hosts have, for whatever reason, been inadvertently
   configured with the same address, and both are simultaneously in the
   process of probing that address to see if it can safely be used.

   NOTE: The check that the packet's 'sender hardware address' is not
   the hardware address of any of the host's interfaces is important.
   Some kinds of Ethernet hub (often called a "buffered repeater") and
   many wireless access points may "rebroadcast" any received broadcast
   packets to all recipients, including the original sender itself.  For
   this reason, the precaution described above is necessary to ensure
   that a host is not confused when it sees its own ARP packets echoed
   back.

   A host implementing this specification MUST take precautions to limit
   the rate at which it probes for new candidate addresses: If the host
   experiences MAX_CONFLICTS or more address conflicts on a given
   interface, then the host MUST limit the rate at which it probes for
   new addresses on this interface to no more than one per
   RATE_LIMIT_INTERVAL.  This is to prevent catastrophic ARP storms in
   pathological failure cases, such as a defective DHCP server that
   repeatedly assigns the same address to every host that asks for one.
   This rate limiting rule applies not only to conflicts experienced
   during the initial probing phase, but also to conflicts experienced
   later, as described in Section 2.4 "Ongoing Address Conflict
   Detection and Address Defense".

   If, by ANNOUNCE_WAIT seconds after the transmission of the last ARP
   Probe no conflicting ARP Reply or ARP Probe has been received, then
   the host has successfully determined that the desired address may be
   used safely.






Expires 11th January 2006             Cheshire                  [Page 9]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


2.2 Shorter Timeouts on Appropriate Network Technologies

   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 values
   for PROBE_WAIT, PROBE_NUM, PROBE_MIN and PROBE_MAX on those
   technologies.

   If the situation arises where different hosts on a link are using
   different timing parameters, this does not cause any problems.  This
   protocol is not dependent on all hosts on a link implementing the
   same version of the protocol; indeed, this protocol is not dependent
   on all hosts on a link implementing the protocol at all.  All that is
   required is that all hosts implement ARP as specified in RFC 826, and
   correctly answer ARP Requests they receive.  In the situation where
   different hosts are using different timing parameters, all that will
   happen is that some hosts will configure their interfaces quicker
   than others.  In the unlikely event that an address conflict is not
   detected during the address probing phase, the conflict will still be
   detected by the Ongoing Address Conflict Detection described below in
   Section 2.4.


2.3 Announcing an Address

   Having probed to determine that a desired address may be used safely,
   a host implementing this specification MUST then announce that it
   is commencing to use this address by broadcasting ANNOUNCE_NUM ARP
   announcements, spaced ANNOUNCE_INTERVAL seconds apart.  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.  The host may begin
   legitimately using the IP address immediately after sending the first
   of the two ARP announcements, and the sending of the second ARP
   announcement may be completed asynchronously, concurrent with other
   networking operations the host may wish to perform.


2.4 Ongoing Address Conflict Detection and Address Defense

   Address conflict detection is not limited to only the time of initial
   interface configuration, when a host is sending ARP probes.  Address
   conflict detection is an ongoing process that is in effect for as
   long as a host is using an address.  At any time, if a host receives
   an ARP packet (Request *or* Reply) where the 'sender IP address' is
   (one of) the host's own IP address(es) configured on that interface,


Expires 11th January 2006             Cheshire                 [Page 10]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


   but the 'sender hardware address' does not match any of the host's
   own interface addresses, then this is a conflicting ARP packet,
   indicating some other host also thinks it is validly using this
   address.  To resolve the address conflict, a host MUST respond to a
   conflicting ARP packet as described in either (a), (b) or (c) below:

   (a) Upon receiving a conflicting ARP packet, a host MAY elect to
   immediately cease using the address, and signal an error to the
   configuring agent 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 within the last DEFEND_INTERVAL
   seconds, then it MAY elect to attempt to defend its address by
   recording the time that the conflicting ARP packet was received, and
   then broadcasting one single ARP announcement, giving its own IP and
   hardware addresses as the sender addresses of the ARP.  Having done
   this, the host can then continue to use the address normally without
   any further special action.  However, if this is not the first
   conflicting ARP packet the host has seen, and the time recorded for
   the previous conflicting ARP packet is recent, within DEFEND_INTERVAL
   seconds, then the host MUST immediately cease using this address and
   signal an error to the configuring agent 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.

   (c) If a host has been configured such that it should not give up its
   address under any circumstances (perhaps because it is the kind of
   device that needs to have a well-known stable IP address, such as a
   link's default router, or a DNS server) then it MAY elect to defend
   its address indefinitely.  If such a host receives a conflicting ARP
   packet, then it should take appropriate steps to log useful
   information such as source Ethernet address from the ARP packet, and
   inform an administrator of the problem.  The number of such
   notifications should be appropriately controlled to prevent an
   excessive number of error reports being generated.  If the host has
   not seen any other conflicting ARP packets recently within the last
   DEFEND_INTERVAL seconds then it MUST record the time that the
   conflicting ARP packet was received, and then broadcast one single
   ARP announcement, giving its own IP and hardware addresses.  Having
   done this, the host can then continue to use the address normally
   without any further special action.  However, if this is not the
   first conflicting ARP packet the host has seen, and the time recorded
   for the previous conflicting ARP packet is within DEFEND_INTERVAL
   seconds then the host MUST NOT send another defensive ARP
   announcement.  This is necessary to ensure that two misconfigured
   hosts do not get stuck in an endless loop flooding the network with
   broadcast traffic while they both try to defend the same address.



Expires 11th January 2006             Cheshire                 [Page 11]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


   A host wishing to provide reliable network operation MUST respond to
   conflicting ARP packets as described in (a), (b) or (c) above.
   Ignoring conflicting ARP packets results in seemingly random network
   failures which can be hard to diagnose and very frustrating for human
   users.

   Forced address reconfiguration may be disruptive, causing TCP
   connections to be broken.  However, such disruptions should be
   exceedingly rare, and if inadvertent address duplication happens,
   then disruption of communication is inevitable.  It is not possible
   for two different hosts using the same IP address on the same network
   to operate reliably.

   Before abandoning an address due to a conflict, hosts SHOULD actively
   attempt to reset any existing connections using that address.  This
   mitigates some security threats posed by address reconfiguration, as
   discussed in Section 3.

   For most client machines that do not need a fixed IP address,
   immediately requesting the configuring agent (human user, DHCP
   client, etc.) to configure 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.

2.5 Broadcast ARP Replies

   In a carefully-run network with manually-assigned addresses, or
   a network with a reliable DHCP server and reliable DHCP clients,
   address conflicts should occur only in rare failure scenarios,
   so the passive monitoring described above in Section 2.4 is adequate.
   If two hosts are using the same IP address, then sooner or later one
   or other host will broadcast an ARP Request, which the other will
   see, allowing the conflict to be detected and consequently resolved.

   It is possible however, that a conflicting configuration may persist
   for a short time before it is detected.  Suppose that two hosts A and
   B have been inadvertently assigned the same IP address X.  Suppose
   further that at the time they were both probing to determine whether
   the address could safely be used, the communication link between them
   was non-functional for some reason, so neither detected the conflict
   at interface-configuration time.  Suppose now that the communication
   link is restored, and a third host C broadcasts an ARP Request for
   address X.  Unaware of any conflict, both hosts A and B will send
   unicast ARP Replies to host C.  Host C will see both Replies, and may
   be a little confused, but neither host A nor B will see the other's
   Reply, and neither will immediately detect that there is a conflict


Expires 11th January 2006             Cheshire                 [Page 12]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


   to be resolved.  Hosts A and B will continue to be unaware of the
   conflict until one or other broadcasts an ARP Request of their own.

   If quicker conflict detection is desired, this may be achieved by
   having hosts send ARP Replies using link-level broadcast, instead of
   sending only ARP Requests via broadcast, and Replies via unicast.
   This is NOT RECOMMENDED for general use, but other specifications
   building on IPv4 ACD may choose to specify broadcast ARP Replies if
   appropriate.  For example, "Dynamic Configuration of IPv4 Link-Local
   Addresses" [RFC3927] specifies broadcast ARP Replies because in that
   context, detection of address conflicts using IPv4 ACD is not merely
   a backup precaution to detect failures of some other configuration
   mechanism; detection of address conflicts using IPv4 ACD is the sole
   configuration mechanism.

   Sending ARP Replies using broadcast does increase broadcast traffic,
   but in the worst case by no more than a factor of two.  In the
   traditional usage of ARP, a unicast ARP Reply only occurs in response
   to a broadcast ARP Request, so sending these via broadcast instead
   means that we generate at most one broadcast Reply in response to
   each existing broadcast Request.  On many networks, ARP traffic is
   such an insignificant proportion of the total traffic that doubling
   it makes no practical difference.  However, this may not be true of
   all networks, so broadcast ARP Replies SHOULD NOT be used
   universally.  Broadcast ARP Replies should be used where the benefit
   of faster conflict detection outweighs the cost of increased
   broadcast traffic and increased packet processing load on the
   participant network hosts.

3. Security Considerations

   IPv4 Address Conflict Detection (ACD) is based on ARP [RFC826] and
   inherits the security vulnerabilities of this protocol.  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.

   This specification makes this existing ARP vulnerability no worse,
   and in some ways makes it better: Instead of failing silently with no
   indication why, hosts implementing this specification either attempt
   to reconfigure automatically, or at least inform the human user of
   what is happening.

   If a host willingly selects a new address in response to an ARP
   conflict, as described in Section 2.4 subsection (a), this
   potentially makes it easier for malicious attackers on the same link
   to hijack TCP connections.  Having a host actively reset any existing
   connections before abandoning an address helps mitigate this risk.


Expires 11th January 2006             Cheshire                 [Page 13]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


4. Historical Note

   A widely-known, but ineffective, duplicate address detection
   technique called "Gratuitous ARP" is found in many deployed systems
   [Ste94].  What Stevens describes as Gratuitous ARP is the exact same
   packet that this document refers to by the more descriptive term "ARP
   Announcement".  This traditional Gratuitous ARP implementation sends
   only a single ARP Announcement when an interface is first configured.
   The result is that the victim (the existing address holder) logs
   an error, and the offender continues operation, often without even
   detecting any problem.  Both machines then typically proceed to try
   to use the same IP address, and fail to operate properly because they
   are each constantly resetting the other's TCP connections.  The human
   administrator is expected to notice the log message on the victim
   machine and repair the damage after the fact.  Typically this has to
   be done by physically going to the machines in question, since in
   this state neither is able to keep a TCP connection open for long
   enough to do anything useful over the network.

   The problems caused by this ineffective duplicate address detection
   technique are illustrated by the fact that (as of August 2004)
   the top Google search results for the phrase "Gratuitous ARP" are
   articles describing how to disable it.

   However, implementers of IPv4 Address Conflict Detection should be
   aware that, as of this writing, Gratuitous ARP is still widely
   deployed.  The steps described in Sections 2.1 and 2.4 of this
   document help make a host robust against misconfiguration and address
   conflicts, even when the other host is *not* playing by the same
   rules.


5. Why are ARP Announcements performed using ARP Request packets
   and not ARP Reply packets?

   During IETF deliberation of IPv4 Address Conflict Detection from 2000
   to 2005, a question that kept being asked repeatedly was, "Shouldn't
   ARP Announcements be performed using gratuitous ARP Reply packets?"

   On the face of it, this seems reasonable.  A conventional ARP Reply
   is an answer to a question.  If in fact no question had been asked,
   then it would be reasonable to describe such a reply as gratuitous.
   This description would seem to apply perfectly to an ARP
   Announcement: an answer to an implied question that in fact no one
   asked.

   However reasonable this may seem in principle, there are two reasons
   why in practice ARP Request packets are the better choice.  One is
   historical precedent, and the other is practicality.


Expires 11th January 2006             Cheshire                 [Page 14]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


   The historical precedent is that, as described above in Section 4,
   Gratuitous ARP is described in Stevens Networking [Ste94] as using
   ARP Request packets.  BSD Unix, Windows, Mac OS 9, Mac OS X, etc.
   all use ARP Request packets as described in Stevens.  At this stage,
   trying to mandate that they all switch to using ARP Reply packets
   would be futile.

   The practical reason is that ARP Request packets are more likely to
   work correctly with more existing ARP implementations, some of which
   may not implement RFC 826 correctly.  The Packet Reception rules in
   RFC 826 state that the opcode is the last thing to check in packet
   processing, so it really shouldn't matter, but there may be
   "creative" implementations that have different packet processing
   depending on the ar$op field, and there are several reasons why these
   are more likely to accept gratuitous ARP Requests than gratuitous ARP
   Replies:

   * An incorrect ARP implementation may expect that ARP Replies are
     only sent via unicast.  RFC 826 does not say this, but an incorrect
     implementation may assume it, and the "principle of least surprise"
     dictates that where there are two or more ways to solve a
     networking problem that are otherwise equally good, the one with
     the fewest unusual properties is the one likely to have the fewest
     interoperability problems with existing implementations.  An ARP
     Announcement needs to broadcast information to all hosts on the
     link.  Since ARP Request packets are always broadcast, and ARP
     Reply packets are not, receiving an ARP Request packet via
     broadcast is less surprising than receiving an ARP Reply packet via
     broadcast.

   * An incorrect ARP implementation may expect that ARP Replies are
     only received in response to ARP Requests that have been issued
     recently by that implementation.  Unexpected unsolicited Replies
     may be ignored.

   * An incorrect ARP implementation may ignore ARP Replies where
     ar$tha doesn't match its hardware address.

   * An incorrect ARP implementation may ignore ARP Replies where
     ar$tpa doesn't match its IP address.

   In summary, there are more ways that an incorrect ARP implementation
   might plausibly reject an ARP Reply (which usually occurs as a result
   of being solicited by the client) than an ARP Request (which is
   already expected to occur unsolicited).






Expires 11th January 2006             Cheshire                 [Page 15]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


6. IANA Considerations

   This specification does not request the creation of any new parameter
   registries, nor does it require any other IANA assignments.

7. Acknowledgments

   This document arose as a result of discussions on link-local
   addressing, where it was not clear to many readers which elements of
   link-local address management were specific to that particular
   problem, and which elements were generic and applicable to all IPv4
   address configuration mechanisms.  The following people made valuable
   comments in the course of that work and/or the subsequent editing
   of this document: Bernard Aboba, Randy Bush, Jim Busse, James
   Carlson, Alan Cox, Pavani Diwanji, Ralph Droms, Donald Eastlake 3rd,
   Alex Elder, Peter Ford, Spencer Giacalone, Josh Graessley, Erik
   Guttman, Myron Hattig, Hugh Holbrook, Richard Johnson, Kim Yong-Woon,
   Marc Krochmal, Rod Lopez, Satish Mundra, Thomas Narten, Erik
   Nordmark, Howard Ridenour, Pekka Savola, Daniel Senie, Dieter
   Siegmund, Valery Smyslov and Ryan Troll.

8. Copyright Notice

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.  For the purposes of this document,
   the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights
   in Contributions", published March 2005.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

9. Normative References

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



Expires 11th January 2006             Cheshire                 [Page 16]

Internet Draft       IPv4 Address Conflict Detection      11th July 2005


10. Informative References

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

   [802.3]   ISO/IEC 8802-3 Information technology - Telecommunications
             and information exchange between systems - Local and
             metropolitan area networks - Common specifications - Part
             3:  Carrier Sense Multiple Access with Collision Detection
             (CSMA/CD) Access Method and Physical Layer Specifications,
             (also ANSI/IEEE Std 802.3-1996), 1996.

   [802.5]   ISO/IEC 8802-5 Information technology - Telecommunications
             and information exchange between systems - Local and
             metropolitan area networks - Common specifications - Part
             5: Token ring access method and physical layer
             specifications, (also ANSI/IEEE Std 802.5-1998), 1998.

   [802.11]  Information technology - Telecommunications and information
             exchange between systems - Local and metropolitan area
             networks - Specific Requirements Part 11:  Wireless LAN
             Medium Access Control (MAC) and Physical Layer (PHY)
             Specifications, IEEE Std. 802.11-1999, 1999.

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

   [RFC3927] S. Cheshire, B. Aboba, E. Guttman,
             "Dynamic Configuration of IPv4 Link-Local Addresses",
             RFC 3927, May 2005.

   [Ste94]   W. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols",
             Addison-Wesley, 1994.


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 11th January 2006             Cheshire                 [Page 17]


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