Stuart,

I was reading draft-cheshire-ipv4-acd-04, and I was wondering about the
question that's actually explicitly covered in Section 5: Why "ARP
Announcement" with ARP Request?

Section 5. lists 2 reasons:
1. Historical precedence: [trying to avoid endless debate] there is also
   precedence for the use of ARP Reply, as well as OS implementation
   that use ARP Reply for gratuitous arp. IIRC, Comer describes Grat ARP
   using ARP Reply opcode; googling for it,
  http://www.listproc.bucknell.edu/archives/netbook/200010/msg00000.html
2. Practicality: This argument lists possible implementation bugs of ARP
   reception, but OTOH the document also says:
	"all that is required is that the peers on the same link
	correctly implement the ARP protocol as given in RFC 826."
   and
	"... so any host that correctly implements the Packet Reception
	algorithm specified in RFC 826 will correctly handle ARP
	Replies delivered via link-layer broadcast."

Given that, as already pointed out in draft-cheshire-ipv4-acd-04, the
source IP address (ar$spa) is processed before the opcode (ar$op), and
the opcode is in fact the last field checked in the ARP "Packet
Reception", then it doesn't really matter if using REQUEST or REPLY.
>From RFC 826, the ARP cache is refreshed before parsing the opcode.

Other specifications mention grat ARPs, and some using reply opcode. For
example, RFC2131 says:
	"The client SHOULD broadcast an ARP reply to announce the
	client's new IP address and clear any outdated ARP cache entries
	in hosts on the client's subnet."
And draft-ietf-mobileip-protocol went:
from -14:
	"A Gratuitous ARP is an ARP Reply that is sent without having
	been prompted by the receipt of any ARP Request.  The ARP Reply
	is..."
to -15:
	"A  Gratuitous ARP [24] is an ARP packet sent by a node in order
	to spontaneously cause other nodes to update an entry in their
	ARP cache.  A gratuitous ARP MAY use either an ARP Request or an
	ARP Reply packet."

On the flip side, as an example, RFC3768 uses a Request opcode:
	"Broadcast a gratuitous ARP request..."

I really do not want to generate a debate on which opcode should be used
for grat arp, but cannot help but wonder: why doesn't
draft-cheshire-ipv4-acd-04 allow for the use of either ar$op, since it
really doesn't matter, and for "ARP Announcement", the processing
happens before even getting to the opcode. I understand the desire to
not leave things unspecified, but IMHO there's precedence (in RFCs and
literature) and reasons for using either opcode for grat arps, and maybe
not taking sides with each one (i.e., allowing both) is a more
comprehensive approach.


One additional small question: Why, for "ARP Probes", ar$tha "SHOULD be
set to all zeroes" and not all ones, when RFC826 says:
	"It does not set ar$tha to anything in particular, because it is
	this value that it is trying to determine.  It could set ar$tha
	to the broadcast address for the hardware (all ones in the case
	of the 10Mbit Ethernet)..."


Also, I agree with the comment (and resolution) for the applicability to
routers, specifically in the value of logging (when some IP addresses
should likely not be changed, even if conflict detected).

Thanks,

--Carlos.


On 2/13/2007 10:19 AM, Mark Townsley allegedly said the following:
> 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
>> Int-area@lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/int-area
>>
>>   
> 
> _______________________________________________
> Int-area mailing list
> Int-area@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area