Network Working Group T.-S. Jou
INTERNET-DRAFT IBM Corporation
Updates: RFC 826 February, 1999
Duplicate IP Address Detection Based on Gratuitous ARP
<draft-jou-duplicate-ip-address-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
The Address Resolution Protocol specifies the scheme to resolve the
hardware address of a host by using its IP address. The hardware
addresses are normally unique for each hardware module because they
were assigned by manufacturers; but there is much less control on the
uniqueness of IP addresses on a LAN. With the booming network
popularity, the possibility of the same IP address being used on
different hosts is increasing. The duplication may come from users'
or network administrators' mistakes, or configuration errors on host
addresses assigning programs such as BOOTP or DHCP servers. This
document is to define an extension to the original ARP protocol to
prevent a newly configured host from making much damage to a host
that has been the owner of the same IP address. The solution is
based on the de-facto gratuitous ARP packets with modification on a
host's behavior when an address duplication is detected.
Jou [Page 1]
INTERNET_DRAFT Duplicate IP Address Detection February, 1999
Acknowledgments
This document was first prepared while the author was an IBM
employee. The initial idea was confirmed and tested with help from
Lori Napoli and Sajay Khanna in IBM. Thanks also go to Mike Patton
in MAP Network Engineering, Inc., for pointing out the security
concerns.
1. Introduction
The Address Resolution Protocol, defined in RFC 826 [1], is used
to determine a host's hardware address based on its network address.
To adapt to the possible changes of the association between a
hardware address and an IP address, two mechanisms are specified in
the RFC:
(1) When a host receives an ARP packet and the sender IP address
exists in its ARP table, the host should update the cached
ARP entry with the sender hardware address in the packet.
(2) Each host ages away old ARP entries to allow changes on the
network.
There are increasing number of hosts that are connected to networks
and have IP addresses assigned, some of them dynamically, hence there
are increasing number of possibilities that the same IP address is
assigned to multiple hosts on a LAN. RFC 826 oversees this problem.
Later in this document we can see the above mechanisms even causes
catastrophic problems. If address duplication ever occurs,
neither of the two hosts sharing the same address can be reliably
reached by others because the unpredictable hardware address
resolution on the shared IP address. This is especially a serious
threat to a server that many clients depend on.
The problem can be avoided gracefully if following three conditions
are achieved:
(a) The host that attempts to use a duplicate IP address can detect
this address is being used by another host, and stop using this
address immediately, possibly via turning down its interface.
(b) The host that originally owns the IP address notifies the
the attempting host for the duplication, and then keep operating.
(c) The confusion caused by the second host's attempt can be reduced
to minimum for all other hosts on the network.
A host running one of many latest TCP/IP implementations can generate
a gratuitous ARP packet when any of its interfaces is configured,
usually at booting time. The gratuitous ARP packet is an ARP request
with both sender and the target IP address fields containing the
configured IP address. This de-facto behavior can be deployed to
detect IP address duplication. After seeing the gratuitous packets, a
Jou [Page 2]
INTERNET_DRAFT Duplicate IP Address Detection February, 1999
host following RFC 826 will send an ARP reply if the address is being
configured on one of its interfaces. Due to the lack of standards,
once the gratuitous ARP sender receives the unexpected ARP reply, the
response varies. Most implementations can display warning messages
on their consoles or to create error logs. Some implementation allows
both hosts to keep using this IP address until the problem is
corrected manually. Some other implementations disable the networking
capability on both hosts and require both hosts to be reconfigured
and possibly be rebooted. The latter implementation makes the hosts
very vulnerable to configuration errors. The correct behavior should
be that the host originally owns this IP address keeps operating,
while error messages are reported to draw network administrator's
attention. The host that attempts to use a duplicate IP address
should stop operating on this address.
The problem cannot be fully solved without addressing Condition (c).
Since a gratuitous ARP request is a link-layer broadcast packet, all
hosts on the network will receive it. According to RFC 826, all hosts
that have this IP address cached in their ARP tables will update the
entry with the sender hardware address. This behavior originally is
designed to allow a host that has just changed its hardware address
(such as interface card is replaced) to be able to update others.
However, this design results in these hosts not being able to reach
the original IP address owner until their ARP entry expires, even if
the gratuitous ARP sender stops using the address immediately. Since
the gratuitous ARP packet just updated every host's ARP entry, the
entry will be valid for the full ARP entry lifetime, normally 20
minutes.
As specified by RFC 826, the ARP reply from the original IP address
owner is a unicast packet, hence the hosts with the ARP entry cached
will not be aware of the occurrence of duplication. To correct the
problem, this document specifies the reply of the gratuitous ARP to
be a link-layer broadcast packet, hence Condition (c) can be achieved
because all other hosts will be able to receive the ARP reply and
change their cached entries back to destine to the original address
owner. Even thought there is still a window of time that the cached
entries are destined to the gratuitous ARP sender, the time period is
much shorter than the ARP entry lifetime.
2. Discussion of an Alternative to Broadcast Reply
An alternative to replying with a broadcast ARP reply packet is to
let the original address owner to send a gratuitous ARP packet again,
which can correct other hosts' cached entries as well. However, if
for whatever reason the host attempting to use the duplicate IP
address chooses to continue operating, that host will reply with an
ARP packet. Once the original address owner receives the reply, it
becomes a protocol dilemma whether to send another gratuitous ARP,
which potentially can cause an infinite looping of ARP packets
between the two hosts, or, to hand over the IP address to the new
host, which violates Condition (b) we would like to achieve.
Jou [Page 3]
INTERNET_DRAFT Duplicate IP Address Detection February, 1999
On the other hand, if the link-layer broadcast ARP reply is sent by
the original address owner but for some reason the host attempting to
use the duplicate IP address is still operating, those hosts that
have the ARP entry cached will be able to keep communicating with the
original address owner until their ARP entries expire. Since these
entries are updated by the broadcast reply, they will remain valid
for approximately the full entry lifetime. But those hosts that have
to resolve this IP address will see undetermined results. However, if
the duplication problem can be fixed in time, perhaps manually by the
users or the network administrator, the proposed scheme still causes
lesser damage to all hosts on the network.
3. The Solution
The implementation details of the solution is described in this
section. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
(1) A gratuitous ARP request packet MUST be generated in two
situations:
(i) when an IP address is being assigned to a working interface,
and
(ii) when an interface that has IP address assigned is being
turned up from down.
A gratuitous ARP packet on an Ethernet is defined as
48.bit Destination Address = 0xffffffffffff (broadcast)
48.bit Source Address = Hardware address of interface
16.bit Frame type = 0x806 (ARP)
----------------------
16.bit Hardware type = 0x1 (Ethernet)
16.bit Protocol Type = 0x800 (IP)
8.bit Hardware Address size = 6
8.bit Protocol Address size = 4
16.bit Opcode = 1 (Request)
48.bit Sender Ethernet Address = Hardware address of interface
32.bit Sender IP Address = Configured IP address
48.bit Target Ethernet Address = Don't care
32.bit Target IP Address = Configured IP Address
(2) If a host receives an ARP request packet in which the target IP
address and the sender IP address fields are the same and it
matches the address of the receiving interface, it implies
IP address duplication happens. The host MUST send a link-layer
broadcast ARP reply as defined below. The host SHOULD report,
log, and/or display warning messages to indicate the detection of
IP address duplication.
Jou [Page 4]
INTERNET_DRAFT Duplicate IP Address Detection February, 1999
48.bit Destination Address = 0xffffffffffff (broadcast)
48.bit Source Address = Hardware address of interface
16.bit Frame type = 0x806 (ARP)
----------------------
16.bit Hardware type = 0x1 (Ethernet)
16.bit Protocol Type = 0x800 (IP)
8.bit Hardware Address size = 6
8.bit Protocol Address size = 4
16.bit Opcode = 2 (Reply)
48.bit Sender Ethernet Address = Hardware address of interface
32.bit Sender IP Address = Local IP address
48.bit Target Ethernet Address = Sender Addr in Request packet
32.bit Target IP Address = Local IP Address
(3) Within a small time period after a host sends a gratuitous ARP
packet, if the host receives an ARP reply with both sender IP
address and the target IP address fields match the address of the
receiving interface, it MUST stop using this address. If this is
the only address of the interface, the interface MUST be turned
down. If there are multiple IP addresses assigned to the
interface, the implementation can choose to only remove the
affected address and keep the interface operating with other
assigned addresses. The host SHOULD report, log, and/or display
messages to indicate the error. If such a reply packet is
received outside the time period, the host SHOULD only report,
log, and/or display messages, but keep operating with the
address.
4. Backwards Compatibility
The hosts with this solution implemented can coexist with other
hosts that do not have it implemented. The implementation is trivial
and the overhead is very limited. Since one of the primary functions
to fully solve the problem is that the second host stops using the
duplicate IP address, the problem addressed here cannot be
completely avoided unless all hosts on the network follow this
document. However, because many existing TCP/IP implementations
generate gratuitous ARP packet, as well as error reporting when
duplication occurs, running hosts with this solution implemented
can increase the chance of catching the error at earlier stage and
reduce the possible damage made by an error.
5. Security Considerations
The proposed solution can decrease the impact when a user, either
fraudulently or simply by mistake, configures a host with an existing
IP address on the LAN. Nevertheless, the proposed solution is mainly
designed to prevent configuration errors, not for malicious attacks.
If a hacker can fabricate and transmit ARP packets on a LAN, these
packets can easily confuse all hosts on the LAN and to sabotage any
Jou [Page 5]
INTERNET_DRAFT Duplicate IP Address Detection February, 1999
network operations. Preventing malicious attacks within a LAN is
sophisticated, and is out of the scope of this document.
A new security concern introduced by the proposed scheme is by
having a requirement to disable an interface when a suitable ARP
reply is seen. To limit the vulnerability from attacks and network
errors, as described in Step (3) of the solution, this disabling
SHOULD only happen if the reply is received within some time period
of sending out a gratuitous ARP request. A RECOMMENDED default period
is 3 seconds, which is long enough to cover normal operations.
6. Reference
[1] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
RFC 826, MIT, November 1982.
7. Author's Address
Tyan-Shu Jou
Torrent Networking Technologies Corporation
3000 Aerial Center Parkway
Suite 140
Morrisville, NC 27560
U.S.A.
Phone: (919) 468-8466 x233
Email: tsjou@torrentnet.com
8. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Jou [Page 6]
INTERNET_DRAFT Duplicate IP Address Detection February, 1999
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."
Jou [Page 7]