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

Bernard Aboba <> Thu, 08 February 2007 18:10 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1HFDim-0004I6-Lc; Thu, 08 Feb 2007 13:10:12 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1HFDil-0004Fu-Bo for; Thu, 08 Feb 2007 13:10:11 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1HFDik-0003YH-33 for; Thu, 08 Feb 2007 13:10:11 -0500
Received: from ([] by with esmtpa (Exim 4.63) (envelope-from <>) id 1HFDii-000BIy-AB; Thu, 08 Feb 2007 13:10:08 -0500
Received: by (Postfix, from userid 1000) id 97A572627E; Thu, 8 Feb 2007 10:10:09 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89EBA21E1F; Thu, 8 Feb 2007 10:10:09 -0800 (PST)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: aboba
Date: Thu, 08 Feb 2007 10:10:09 -0800
From: Bernard Aboba <>
To: Stuart Cheshire <>
Subject: Re: [Int-area] Review of draft-cheshire-ipv4-acd-04.txt
In-Reply-To: <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
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: <>, <>

> 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