On Fri, 16 Nov 2007, Spencer Dawkins wrote:
address of the interface sending the packet. The 'sender IP address'
field MUST be set to all zeroes, to avoid polluting ARP caches in
other hosts on the same link in the case where the address turns out
to be already in use by another host. The 'target hardware address'
field is ignored and SHOULD be set to all zeroes. The 'target IP
Spencer: why is this SHOULD, and not MUST? I'm not asking for a change,
I'm asking for a clue. I'm suspecting the answer is "some really old
implementations may not do this", and that would be fine if you said
it - just being clear that the SHOULD isn't a license for new
implementations to say "I'm special".
This shouldn't even be a SHOULD because it is not required for
interoperability. It certainly can't be a MUST, as it conflicts
with a suggestion in the original ARP specificaion (RFC 826).
Here is what RFC 826 has to say about how an ARP implementation sets
the target hardware address in an ARP request that it is about to
broadcast:
| 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) if that makes it
| convenient for some aspect of the implementation.
In other words, the target hardware address does not matter and can
be set to any value. I am aware of implementations that follow the
suggestion (which would be a MAY in 2119 parlance) to set ar$tha to
the broadcast address when broadcasting an ARP request.
Here is the guidance from Section 6 or RFC 2119 on the use of
imperatives such as should:
| Imperatives of the type defined in this memo must be used with care
| and sparingly. In particular, they MUST only be used where it is
| actually required for interoperation or to limit behavior which has
| potential for causing harm (e.g., limiting retransmisssions) For
| example, they must not be used to try to impose a particular method
| on implementors where the method is not required for
| interoperability.
I do not see how the above SHOULD enhances interoperability or
limits the potential for causing harm. Insofar as
draft-cheshire-ipv4-acd-05.txt claims not to modify any protocol
rules, its insistence that ar$tha should be set to zero in ARP
request packets certainly looks odd to me.
While I am at it, I also have an issue with the draft's Section 4,
Historical Note. The first sentence reads:
A widely-known, but ineffective, duplicate address detection
technique called "Gratuitous ARP" is found in many deployed systems
[Ste94].
This sentence seems to claim that the intended purpose of
"Gratuitous ARP" was to perform duplicate address detection. That
was not the case. Its purpose was to flush stale entries out of ARP
caches when a station's IP address (or Ethernet address) changed.
See, e.g., RFC 2002 and references therein.
Mike Heard
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf