I have reviewed draft-cheshire-ipv4-acd-04, and recommend that it
be published as a Proposed Standard RFC, with some potential
clarifications.
Some comments:
Section 1 talks about the case where two hosts are simultaneously probing.
(b) the case where two hosts are inadvertently about to begin
using the same address, and both are simultaneously in the process
of probing to determine whether the address may safely be used.
(Section 2.1.)
In the -03 document, there was material in Section 2.1 that addressed this
case. However in the -04 document, this material is now in Section 2.1.1:
" In addition, if during this period the host receives any ARP Probe
where the packet's 'target IP address' is the address being probed
for, and the packet's 'sender hardware address' is not the hardware
address of the interface the host is attempting to configure, then
the host MUST similarly treat this as an address conflict and signal
an error to the configuring agent as above. This can occur if two
(or more) hosts have, for whatever reason, been inadvertently
configured with the same address, and both are simultaneously in the
process of probing that address to see if it can safely be used."
Thus during the probing phase, the Target Protocol Address (ar$tpa) is
treated as an assertion rather than a question. This is somewhat in
conflict with Section 1.2, which states:
" As already specified in RFC 826, an ARP Request packet serves two
functions, an assertion and a question:
* Assertion:
The fields "ar$sha" (Sender Hardware Address) and "ar$spa" (Sender
Protocol Address) together serve as an assertion of a fact, that
the stated Protocol Address is mapped to the stated Hardware
Address.
* Question:
The fields "ar$tha" (Target Hardware Address, zero) and "ar$tpa"
(Target Protocol Address) serve as a question, asking, for the
stated Protocol Address, to which Hardware Address it is mapped."
My recommendation would be to indicate the probe exception within Section
1.2. Since the proposed behavior changes the interpretation of ar$tpa within
RFC 826 from a question to an assertion during probing, I would question
the use of "MUST" in Section 2.1.1 above. SHOULD would probably be better.
The other general issue is the applicability of this document. Much of
the text appears to focus on host examples, but there is nothing that
says that it doesn't also apply to routers.
In my examination of router ARP behavior during the development of DNAv4,
I noticed that many existing routers appear to assume that their IP
address assignments are definitive, either using gratuitous ARP as
described in Section 4, or skipping conflict detection on boot entirely.
As a result, these routers will continue to utilize their configured
addresses regardless of whether a host has also claimed the same address.
While this existing behavior increases the likelihood of unresolved
conflicts, my understanding is that there is some security rationale
behind it. For example, were a router installed in an exchange point
to implement the conflict detection mechanisms described in this
document, then addresses on the interface could be disabled via
use of ARP, causing BGP connections to be reset. Of course, the
same effect could also be achieved by reconfiguring peer routers
to utilize a conflicting address, but the attacks enabled by
implementation of this document would seem harder to trace/detect.
As a result, I am wondering whether this document should tone down
the language in Section 4, perhaps limiting the criticism to hosts,
or addressing the issue of router applicability explicitly in some
other section.
4. Historical Note
A widely-known, but ineffective, duplicate address detection
technique called "Gratuitous ARP" is found in many deployed systems
[Ste94]. What Stevens describes as Gratuitous ARP is the exact same
packet that this document refers to by the more descriptive term "ARP
Announcement". This traditional Gratuitous ARP implementation sends
only a single ARP Announcement when an interface is first configured.
The result is that the victim (the existing address holder) logs
an error, and the offender continues operation, often without even
detecting any problem. Both machines then typically proceed to try
to use the same IP address, and fail to operate properly because they
are each constantly resetting the other's TCP connections. The human
administrator is expected to notice the log message on the victim
machine and repair the damage after the fact. Typically this has to
be done by physically going to the machines in question, since in
this state neither is able to keep a TCP connection open for long
enough to do anything useful over the network.
The problems caused by this ineffective duplicate address detection
technique are illustrated by the fact that (as of August 2004)
the top Google search results for the phrase "Gratuitous ARP" are
articles describing how to disable it.
However, implementers of IPv4 Address Conflict Detection should be
aware that, as of this writing, Gratuitous ARP is still widely
deployed. The steps described in Sections 2.1 and 2.4 of this
document help make a host robust against misconfiguration and address
conflicts, even when the other host is *not* playing by the same
rules.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
