IPv4 Address Conflict Detection
RFC 5227

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Network Working Group                                        S. Cheshire
Request for Comments: 5227                                    Apple Inc.
Updates: 826                                                   July 2008
Category: Standards Track

                    IPv4 Address Conflict Detection

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   When two hosts on the same link attempt to use the same IPv4 address
   at the same time (except in rare special cases where this has been
   arranged by prior coordination), problems ensue for one or both
   hosts.  This document describes (i) a simple precaution that a host
   can take in advance to help prevent this misconfiguration from
   happening, and (ii) if this misconfiguration does occur, a simple
   mechanism by which a host can passively detect, after the fact, that
   it has happened, so that the host or administrator may respond to
   rectify the problem.

Cheshire                    Standards Track                     [Page 1]
RFC 5227            IPv4 Address Conflict Detection            July 2008

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions and Terminology Used in This Document ..........4
      1.2. Relationship to RFC 826 ....................................5
           1.2.1. Broadcast ARP Replies ...............................7
      1.3. Applicability ..............................................7
   2. Address Probing, Announcing, Conflict Detection, and Defense ....9
      2.1. Probing an Address ........................................10
           2.1.1. Probe Details ......................................10
      2.2. Shorter Timeouts on Appropriate Network Technologies ......11
      2.3. Announcing an Address .....................................12
      2.4. Ongoing Address Conflict Detection and Address Defense ....12
      2.5. Continuing Operation ......................................14
      2.6. Broadcast ARP Replies .....................................14
   3. Why Are ARP Announcements Performed Using ARP Request
      Packets and Not ARP Reply Packets? .............................15
   4. Historical Note ................................................17
   5. Security Considerations ........................................17
   6. Acknowledgments ................................................18
   7. References .....................................................18
      7.1. Normative References ......................................18
      7.2. Informative References ....................................19

1.  Introduction

   Historically, accidentally configuring two Internet hosts with the
   same IP address has often been an annoying and hard-to-diagnose
   problem.

   This is unfortunate, because the existing Address Resolution Protocol
   (ARP) provides an easy way for a host to detect this kind of
   misconfiguration and report it to the user.  The DHCP specification
   [RFC2131] briefly mentions the role of ARP in detecting
   misconfiguration, as illustrated in the following three excerpts from
   RFC 2131:

   o the client SHOULD probe the newly received address, e.g., with ARP

   o The client SHOULD perform a final check on the parameters
     (e.g., ARP for allocated network address)

   o If the client detects that the address is already in use
     (e.g., through the use of ARP), the client MUST send a DHCPDECLINE
     message to the server

Cheshire                    Standards Track                     [Page 2]
RFC 5227            IPv4 Address Conflict Detection            July 2008

   Unfortunately, the DHCP specification does not give any guidance
   to implementers concerning the number of ARP packets to send, the
   interval between packets, the total time to wait before concluding
   that an address may safely be used, or indeed even which kinds
   of packets a host should be listening for, in order to make this
   determination.  It leaves unspecified the action a host should
   take if, after concluding that an address may safely be used, it
   subsequently discovers that it was wrong.  It also fails to specify
   what precautions a DHCP client should take to guard against
   pathological failure cases, such as a DHCP server that repeatedly
   OFFERs the same address, even though it has been DECLINEd multiple
   times.

   The authors of the DHCP specification may have been justified in
   thinking at the time that the answers to these questions seemed too
   simple, obvious, and straightforward to be worth mentioning, but
   unfortunately this left some of the burden of protocol design to each