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

[Bernard Aboba <[e-mail]>]

> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area