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)
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| 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
Show full document text