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]