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