Re: [Int-area] Review of draft-cheshire-ipv4-acd-04.txt

Mark Townsley <> Tue, 13 February 2007 15:19 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1HGzRL-0001P0-Ji; Tue, 13 Feb 2007 10:19:31 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1HGzRK-0001Or-S7 for; Tue, 13 Feb 2007 10:19:30 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1HGzRI-0005fw-DA for; Tue, 13 Feb 2007 10:19:30 -0500
Received: from ([]) by with ESMTP; 13 Feb 2007 10:19:28 -0500
X-IronPort-AV: i="4.14,163,1170651600"; d="scan'208"; a="52918853:sNHT51101320"
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id l1DFJS8v006223; Tue, 13 Feb 2007 10:19:28 -0500
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id l1DFJRVT017252; Tue, 13 Feb 2007 10:19:27 -0500 (EST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 10:19:27 -0500
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 10:19:26 -0500
Message-ID: <>
Date: Tue, 13 Feb 2007 16:19:29 +0100
From: Mark Townsley <>
User-Agent: Thunderbird (Macintosh/20061207)
MIME-Version: 1.0
To: Bernard Aboba <>
Subject: Re: [Int-area] Review of draft-cheshire-ipv4-acd-04.txt
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Feb 2007 15:19:26.0312 (UTC) FILETIME=[59226E80:01C74F82]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3889; t=1171379968; x=1172243968; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20Mark=20Townsley=20<> |Subject:=20Re=3A=20[Int-area]=20Review=20of=20draft-cheshire-ipv4-acd-04 .txt |Sender:=20 |To:=20Bernard=20Aboba=20<>; bh=rL9bA6cJtd+1p2LHuHz4lg0c2JJmEy0yR0QdHz0S27E=; b=0crcvX5puKzVN3iOeN7E8rxU2v+787ph+6H0O9Uoj36SpG1/4Ei22PW6xJPiJcZUej1GePx8 rx3mhsYKeqos/Rxcyz90NusC5FgUWtCbo6IaF7TVmVxkC50w67SIeJSa;
Authentication-Results: rtp-dkim-2;; dkim=pass ( sig from verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Thank you Bernard and Stuart. If these are all the comments, I'll issue 
a last call in the next few days. Please folks, weigh in now if you 
intend to.

- Mark

Bernard Aboba wrote:
>> I've added the following paragraph at the end of Section 1.3 
>> "Applicability":
>>    Where this document uses the term "host" it applies equally to
>>    interfaces on routers or other multi-homed hosts, regardless of
>>    whether the host/router is currently forwarding packets. In many
>>    cases a router will be critical network infrastructure with a locally
>>    well-known IP address (e.g. handed out by the local DHCP server to
>>    local clients) so handling conflicts by picking a new IP address is
>>    not an option. In those cases, option (c) in Section 2.4 "Ongoing
>>    Address Conflict Detection and Address Defense" below applies.
>>    However, even when a device is manually configured with a fixed
>>    address, having some other device on the network claiming to have
>>    the same IP address will pollute peer ARP caches and prevent reliable
>>    communication, so it is still helpful to inform the operator. If a
>>    conflict is detected at the time the operator sets the fixed manual
>>    address then it is helpful to inform the operator immediately;
>>    if a conflict is detected subsequently it is helpful to inform the
>>    operator via some appropriate asynchronous communications channel.
>>    Even though reliable communication via the conflicted address is not
>>    possible, it may still be possible to inform the operator via some
>>    other communication channel that is still operating, such as via some
>>    other interface on the router, via a dynamic IPv4 link-local address,
>>    via a working IPv6 address, or even via some completely different
>>    non-IP technology such as a locally-attached screen or serial
>>    console.
> This looks good. 
>> Informing the operator of the detected conflict allows the 
>> problem to be identified and solved quickly. Ignoring the conflict can 
>> lead to the issue being misdiagnosed and unresolved, causing a lot of 
>> frustration. If you've ever had two non-ACD devices with the same IP 
>> address, you'll know that the symptoms of random intermittent pauses and 
>> TCP connection failures can easily be mistaken for a bad cable or 
>> defective Ethernet hub.
> I agree that informing the operator is a good idea. 
>> I disagree. The technique of sending a single ARP Announcement and not 
>> paying attention to any responses is extremely ineffective at coping with 
>> the case of two devices that think they have the same IP address. The 
>> only case where it does anything useful is the case where the old device 
>> has been retired from the network in the last minute or two; it's MAC 
>> address still remains in peer ARP caches, and when the new device is 
>> attached to the network, it's single ARP Announcement serves to update 
>> those stale ARP caches. Updating peer ARP caches is important (which is 
>> why we have ARP Announcements) but that alone does nothing to detect, 
>> report, or remedy the problems of inadvertent duplicate address 
>> conflicts. In short, it's a necessary part of a larger solution, but it 
>> is not a complete solution in itself.
> I agree that it's a bad idea not to pay attention to responses.  The 
> comment was really only about router address changes, which are covered in 
> the other updates. 
>> If you agree with my comments and changes, I'll submit an updated 
>> draft-05 for publication in a few days.
> The changes look good. 
> _______________________________________________
> Int-area mailing list

Int-area mailing list