Internet Draft 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]