RFC 5227 – IPv4 Address Conflict Detection

RFC 5227 – IPv4 Address Conflict Detection

he same IP address, X.
   Suppose further that at the time they were both probing to determine



Cheshire                    Standards Track                    [Page 14]

RFC 5227            IPv4 Address Conflict Detection            July 2008


   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 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.  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 2008, a question that was 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.



Cheshire                    Standards Track                    [Page 15]

RFC 5227            IPv4 Address Conflict Detection            July 2008


   The term "gratuitous reply" 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, in practice there are
   two reasons that swing the argument in favor of using ARP Request
   packets.  One is historical precedent, and the other is pragmatism.

   The historical precedent is that (as described above in Section 4)
   Gratuitous ARP is documented in Stevens Networking [Ste94] as using
   ARP Request packets.  BSD Unix, Microsoft 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 entirely 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; 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.



Cheshire                    Standards Track                    [Page 16]

RFC 5227            IPv4 Address Conflict Detection            July 2008


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

4.  Historical Note

   Some readers have claimed that "Gratuitous ARP", as described in
   Stevens [Ste94], provides duplicate address detection, making ACD
   unnecessary.  This is incorrect.  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.

   Gratuitous ARP does not in fact provide effective duplicate address
   detection and (as of January 2008) many of the top results for a
   Google search 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.  Security Considerations

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






Cheshire                    Standards Track                    [Page 17]

RFC 5227            IPv4 Address Conflict Detection            July 2008


   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.

6.  Acknowledgments

   This document arose as a result of Zeroconf Working Group discussions
   on IPv4 Link-Local Addressing [RFC3927], where it was not clear to
   many participants which elements of link-local address management
   were specific to that particular problem space (e.g., random
   selection of an address), and which elements were generic and
   applicable to all IPv4 address configuration mechanisms (e.g., the
   detection of address conflicts).  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, Spencer Dawkins, Pavani Diwanji, Ralph Droms, Donald
   Eastlake III, Alex Elder, Stephen Farrell, Peter Ford, Spencer
   Giacalone, Josh Graessley, Erik Guttman, Myron Hattig, Mike Heard,
   Hugh Holbrook, Richard Johnson, Kim Yong-Woon, Marc Krochmal, Rod
   Lopez, Rory McGuire, Satish Mundra, Thomas Narten, Erik Nordmark,
   Randy Presuhn, Howard Ridenour, Pekka Savola, Daniel Senie, Dieter
   Siegmund, Valery Smyslov, Mark Townsley, Oleg Tychev, and Ryan Troll.

7.  References

7.1.  Normative References

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

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









Cheshire                    Standards Track                    [Page 18]

RFC 5227            IPv4 Address Conflict Detection            July 2008


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

   [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
             and E. Lear, "Address Allocation for Private Internets",
             BCP 5, RFC 1918, February 1996.

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

   [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
             reconfigure extension", RFC 3203, December 2001.

   [RFC3927] Cheshire, S., Aboba, B., and 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.











Cheshire                    Standards Track                    [Page 19]

RFC 5227            IPv4 Address Conflict Detection            July 2008


Author's Address

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

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








































Cheshire                    Standards Track                    [Page 20]

RFC 5227            IPv4 Address Conflict Detection            July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.












Cheshire                    Standards Track                    [Page 21]