idnits 2.17.1 draft-jou-duplicate-ip-address-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 75 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 137: '...P request packet MUST be generated whe...' RFC 2119 keyword, line 163: '...appens. The host MUST send a link laye...' RFC 2119 keyword, line 164: '...efined below. The host MAY also log or...' RFC 2119 keyword, line 184: '... it MUST turn off the interface t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 29, 1998) is 9333 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T.-S. Jou 3 INTERNET-DRAFT IBM Corp. 4 Updates: RFC 826 September 29, 1998 5 Category: Experimental 7 Duplicate IP Address Detection Based on Gratuitous ARP 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 This memo defines an Experimental Protocol for the Internet 31 community. This memo does not specify an Internet standard of any 32 kind. Discussion and suggestions for improvement are requested. 33 Distribution of this memo is unlimited. 35 Copyright Notice 37 Copyright (C) THe Internet Society (1998). All Rights Reserved. 39 Abstract 41 The Address Resolution Protocol defines the way to resolve the 42 hardware address of a host on a broadcast network based on the 43 target host's IP address. The hardware address is always unique 44 for each hardware module, but no guarantee on the uniqueness of IP 45 addresses. With current trend of connecting every hosts, 46 the chance of the same IP address is used on different hosts is 47 increasing due to users' or network administrators' mistake, 48 or a configuration error from an IP address assigning program such 49 as a BOOTP or DHCP server. This memo is to define an extention to 50 the original protocol to prevent a newly configured host from making 51 any damage to the host that has been the owner of the same IP 52 address. The solution is based on using the de-facto gratuitous ARP 53 packet plus modification on processing of this packet. 55 Acknowledgments 57 The memo proposed here is a result of a discussion with my collegues 58 Lori Napoli and Sanjay Khanna. Also very thankful for their review. 60 RFC nnnn Duplicate IP Address Detection September 4, 1998 62 1. Introduction 64 The Address Resolution Protocol, as defined in RFC 826 [1], is used 65 to determine a host's IP address based on its network address. To 66 adapt to the possible changes of the association between a hardware 67 address and an IP address, two mechanisms are described: 69 (1) When a host receives an ARP packet and the sender's IP address 70 exists in its ARP table, the host should update the cached 71 ARP entry with the sender's hardware address in the packet. 72 (2) Each host ages away old ARP entries to allow changes on the 73 network. 75 With the popularity of today's internet activities, more and more 76 hosts are connected to networks and have IP addresses assigned. 77 There are increasing chance of the same IP address being used on two 78 different hosts due to any kind of error. If this ever happens, 79 neither of the the two hosts can reliably communicate to others 80 because the unpredictable hardware address resolution on this shared 81 IP address. This is especially a serious threat to a server that many 82 clients depend on. 84 The problem can be avoided gracefully if all following conditions 85 are achieved: 87 (a) The second host that tries to use the same IP address detects 88 another host is using this address, and turns down its interface. 89 (b) The host that originally owns the IP address notifies the 90 the second host for the duplication and then can keep operating. 91 (c) All other hosts on the network are not confused by the second 92 host's attempt. 94 A host running one of many recent TCP/IP implementations can 95 generate a gratuitous ARP request packet when any of its interfaces 96 is configured, usually at booting time. The gratuitous ARP packet is 97 an ARP request with both sender's and the target's IP address fields 98 containing the configured IP address. This de-facto behavior allows 99 any other host following the original protocol to detect the 100 duplication and to send an ARP reply. Once the host that sends the 101 gratuitous ARP receives the unexpected ARP reply, it may choose to 102 display a warning on its console or keep an error log on the system 103 but may keep using this IP address until it is corrected 104 manually. This can be corrected if the second host can send 105 gratuitous ARP and turn down its interface if a reply is received. 106 On the opposite, if IP address duplication is detected, some 108 RFC nnnn Duplicate IP Address Detection September 4, 1998 110 implementations disable the networking capability on both hosts 111 and require both hosts to be reconfigured and possibly be rebooted, 112 which makes it too easy to cause a host to stop working. 113 The host that originally owns this IP address should keep operating, 114 although an error message may be used to draw network administrator's 115 attention. 117 The problem cannot be fully solved without addressing the 118 condition (c). Because the gratuitous ARP request is a link layer 119 broadcast packet, all hosts on the network will receive it. According 120 to the ARP described in RFC 826, all hosts that have this IP 121 address cached in their ARP tables will update the entries with 122 the sender's hardware address. This results in these hosts not 123 being able to communicate with the original IP address owner until 124 its ARP entry expires. According to RFC 826, the ARP reply from 125 the original IP address owner is a unicast packet, so these hosts 126 do not aware of the duplication. However, if the reply of the 127 gratuitous ARP is generated as a link layer broadcast packet, 128 condition (c) would be achieved. An alternative is to let the 129 original owner to send a gratuitous ARP packet again. However, this 130 alternative can potentially cause a gratuitous ARP packets flooding 131 if the duplicated IP address host chooses to continue running. 133 2. The Solution 135 This memo recommends all hosts to follow the actions listed below: 137 (i) An gratuitous ARP request packet MUST be generated when a working 138 interface is configured with an IP address and when an interface 139 that has been configured with an IP address is being turned up 140 from down. 142 A gratuitous ARP packet on an Ethernet is defined as 144 48.bit Destination Address = 0xffffffffffff (broadcast) 145 48.bit Source Address = Hardware adderss of interface 146 16.bit Frame type = 0x806 (ARP) 147 ---------------------- 148 16.bit Hardware type = 0x1 (Ethernet) 149 16.bit Protocol Type = 0x800 (IP) 150 8.bit Hardware Address size = 6 151 8.bit Protocol Address size = 4 152 16.bit Opcode = 1 (Request) 153 48.bit Sender Ethernet Address = Hardware address of interface 154 32.bit Sender IP Address = Configured IP address 155 48.bit Target Ethernet Address = Don't care 156 32.bit Target IP Address = Configured IP Address 158 RFC nnnn Duplicate IP Address Detection September 4, 1998 160 (ii) If a host receives an ARP request packet in which the 161 Target IP address and the Sender IP address are the same and it 162 matches one of its interface addresses, it then implies 163 IP address duplication happens. The host MUST send a link layer 164 broadcast ARP reply as defined below. The host MAY also log or 165 display warning messages to indicate the detection of IP address 166 duplication. 168 48.bit Destination Address = 0xffffffffffff (broadcast) 169 48.bit Source Address = Hardware adderss of interface 170 16.bit Frame type = 0x806 (ARP) 171 ---------------------- 172 16.bit Hardware type = 0x1 (Ethernet) 173 16.bit Protocol Type = 0x800 (IP) 174 8.bit Hardware Address size = 6 175 8.bit Protocol Address size = 4 176 16.bit Opcode = 2 (Reply) 177 48.bit Sender Ethernet Address = Hardware address of interface 178 32.bit Sender IP Address = Local IP address 179 48.bit Target Ethernet Address = Sender Addr in Request packet 180 32.bit Target IP Address = Local IP Address 182 (iii) If a host receives an ARP reply with both sender IP address 183 and the target IP address fields match one of its interfaces, 184 it MUST turn off the interface to stop using this address. 185 It May log or display warning messages to indicate the error. 187 3. Backwards Compatibility 189 The hosts with this solution implemented can coexist with other 190 hosts that do not have it implemented. The implementation is trivial 191 and the overhead is very limited. Since the key to solve the problem 192 is that the second host stops using the duplicate IP address, the 193 problem addressed here cannot be completely avoided unless all hosts 194 on the network follow this memo. However, because many existing 195 TCP/IP implementations generate gratuitous ARP packet, and also 196 many TCP/IP implementations can generate warnings, disable 197 networking or even reboot whenener the host receives an ARP packet 198 with the sender address matches its interface IP address, running 199 hosts with this solution implemented can increase the chance of 200 catching the error at earlier stage. 202 4. Security Considerations 204 Security issues are not discussed in this memo. 206 RFC nnnn Duplicate IP Address Detection September 4, 1998 208 5. References 210 [1] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, 211 RFC 826, MIT, November 1982. 213 6. Author's Address 215 Tyan-Shu Jou 216 3039 Cornwallis 217 Dept TDUA / Bldg. 205 218 Research Triangle Park, NC 27709 219 U.S.A. 221 Phone: (919) 254-2839 222 Email: tjou@us.ibm.com 224 7. Full Copyright Statement 226 Copyright (C) The Internet Society (1997). All Rights Reserved. 228 This document and translations of it may be copied and furnished to 229 others, and derivative works that comment on or otherwise explain it 230 or assist in its implmentation may be prepared, copied, published and 231 distributed, in whole or in part, without restriction of any kind, 232 provided that the above copyright notice and this paragraph are 233 included on all such copies and derivative works. However, this 234 document itself may not be modified in any way, such as by removing 235 the copyright notice or references to the Internet Society or other 236 Internet organizations, except as needed for the purpose of 237 developing Internet standards in which case the procedures for 238 copyrights defined in the Internet Standards process must be 239 followed, or as required to translate it into languages other than 240 English. 242 The limited permissions granted above are perpetual and will not be 243 revoked by the Internet Society or its successors or assigns. 245 This document and the information contained herein is provided on an 246 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 247 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 248 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 249 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 250 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."