IPv4 Address Conflict Detection
RFC 5227
Document | Type |
RFC - Proposed Standard
(July 2008; No errata)
Updates RFC 826
Was draft-cheshire-ipv4-acd (individual in int area)
|
|
---|---|---|---|
Author | Stuart Cheshire | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5227 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Mark Townsley | ||
Send notices to | <cheshire@apple.com> |
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 eachShow full document text