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

[Mark Townsley <[e-mail]>]

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

_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area