[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

 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
                <draft-jou-duplicate-ip-address-01.txt>

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/