Network Working Group T.-S. Jou INTERNET-DRAFT IBM Corp. Updates: RFC 826 September 29, 1998 Category: Experimental Duplicate IP Address Detection Based on Gratuitous ARP Status of this Memo This document is an Internet-Draft. 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 entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) THe Internet Society (1998). All Rights Reserved. Abstract The Address Resolution Protocol defines the way to resolve the hardware address of a host on a broadcast network based on the target host's IP address. The hardware address is always unique for each hardware module, but no guarantee on the uniqueness of IP addresses. With current trend of connecting every hosts, the chance of the same IP address is used on different hosts is increasing due to users' or network administrators' mistake, or a configuration error from an IP address assigning program such as a BOOTP or DHCP server. This memo is to define an extention to the original protocol to prevent a newly configured host from making any damage to the host that has been the owner of the same IP address. The solution is based on using the de-facto gratuitous ARP packet plus modification on processing of this packet. Acknowledgments The memo proposed here is a result of a discussion with my collegues Lori Napoli and Sanjay Khanna. Also very thankful for their review. Jou Experimental [Page 1] RFC nnnn Duplicate IP Address Detection September 4, 1998 1. Introduction The Address Resolution Protocol, as defined in RFC 826 [1], is used to determine a host's IP 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 described: (1) When a host receives an ARP packet and the sender's IP address exists in its ARP table, the host should update the cached ARP entry with the sender's hardware address in the packet. (2) Each host ages away old ARP entries to allow changes on the network. With the popularity of today's internet activities, more and more hosts are connected to networks and have IP addresses assigned. There are increasing chance of the same IP address being used on two different hosts due to any kind of error. If this ever happens, neither of the the two hosts can reliably communicate to others because the unpredictable hardware address resolution on this shared IP address. This is especially a serious threat to a server that many clients depend on. The problem can be avoided gracefully if all following conditions are achieved: (a) The second host that tries to use the same IP address detects another host is using this address, and turns down its interface. (b) The host that originally owns the IP address notifies the the second host for the duplication and then can keep operating. (c) All other hosts on the network are not confused by the second host's attempt. A host running one of many recent TCP/IP implementations can generate a gratuitous ARP request packet when any of its interfaces is configured, usually at booting time. The gratuitous ARP packet is an ARP request with both sender's and the target's IP address fields containing the configured IP address. This de-facto behavior allows any other host following the original protocol to detect the duplication and to send an ARP reply. Once the host that sends the gratuitous ARP receives the unexpected ARP reply, it may choose to display a warning on its console or keep an error log on the system but may keep using this IP address until it is corrected manually. This can be corrected if the second host can send gratuitous ARP and turn down its interface if a reply is received. On the opposite, if IP address duplication is detected, some Jou Experimental [Page 2] RFC nnnn Duplicate IP Address Detection September 4, 1998 implementations disable the networking capability on both hosts and require both hosts to be reconfigured and possibly be rebooted, which makes it too easy to cause a host to stop working. The host that originally owns this IP address should keep operating, although an error message may be used to draw network administrator's attention. The problem cannot be fully solved without addressing the condition (c). Because the gratuitous ARP request is a link layer broadcast packet, all hosts on the network will receive it. According to the ARP described in RFC 826, all hosts that have this IP address cached in their ARP tables will update the entries with the sender's hardware address. This results in these hosts not being able to communicate with the original IP address owner until its ARP entry expires. According to RFC 826, the ARP reply from the original IP address owner is a unicast packet, so these hosts do not aware of the duplication. However, if the reply of the gratuitous ARP is generated as a link layer broadcast packet, condition (c) would be achieved. An alternative is to let the original owner to send a gratuitous ARP packet again. However, this alternative can potentially cause a gratuitous ARP packets flooding if the duplicated IP address host chooses to continue running. 2. The Solution This memo recommends all hosts to follow the actions listed below: (i) An gratuitous ARP request packet MUST be generated when a working interface is configured with an IP address and when an interface that has been configured with an IP address 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 adderss 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 Jou Experimental [Page 3] RFC nnnn Duplicate IP Address Detection September 4, 1998 (ii) If a host receives an ARP request packet in which the Target IP address and the Sender IP address are the same and it matches one of its interface addresses, it then implies IP address duplication happens. The host MUST send a link layer broadcast ARP reply as defined below. The host MAY also log or display warning messages to indicate the detection of IP address duplication. 48.bit Destination Address = 0xffffffffffff (broadcast) 48.bit Source Address = Hardware adderss 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 (iii) If a host receives an ARP reply with both sender IP address and the target IP address fields match one of its interfaces, it MUST turn off the interface to stop using this address. It May log or display warning messages to indicate the error. 3. 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 the key to 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 memo. However, because many existing TCP/IP implementations generate gratuitous ARP packet, and also many TCP/IP implementations can generate warnings, disable networking or even reboot whenener the host receives an ARP packet with the sender address matches its interface IP address, running hosts with this solution implemented can increase the chance of catching the error at earlier stage. 4. Security Considerations Security issues are not discussed in this memo. Jou Experimental [Page 4] RFC nnnn Duplicate IP Address Detection September 4, 1998 5. References [1] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, MIT, November 1982. 6. Author's Address Tyan-Shu Jou 3039 Cornwallis Dept TDUA / Bldg. 205 Research Triangle Park, NC 27709 U.S.A. Phone: (919) 254-2839 Email: tjou@us.ibm.com 7. Full Copyright Statement Copyright (C) The Internet Society (1997). 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 implmentation 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. 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 Experimental [Page 5]