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