Thank you Bernard for your comments. Sorry for the delay responding; the
last couple of months were very busy for me with work on Apple's upcoming
iPhone and Apple TV products.
>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.
You've made a very interesting philosophical observation here (that goes
beyond the current topic of networking and packets). It's not possible to
have a truly pure question -- any question can't help also conveying some
hint of the questioner's motives. Why are you asking the question? The
act of asking can't avoid the suggestion that you may carry out some
action based on the answer. I've added the following paragraph at the end
of Section 1.2 to make this explicit:
It has been observed that it is probably impossible to ask any truly
pure question; asking any question necessarily invites speculation
about why the interrogator wants to know the answer. Just as someone
pointing to an empty seat and asking, "Is anyone sitting here?"
implies an unspoken "... because if not then I will," the same is
true here. An ARP Probe with an all-zero 'sender IP address' may
ostensibly be merely asking an innocent question ("Is anyone using
this address?"), but an intelligent implementation that knows how
IPv4 Address Conflict Detection works should be able to recognize
this question as the precursor to claiming the address. Consequently,
if that implementation is also at that exact moment in the process of
asking the very same question, it should recognize that they can't
both sit in the same seat, so it would be prudent to ask about some
other seat.
>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.
Changed.
>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.
I think it would be more accurate to say they "will continue to
*try* (unsuccessfully) to utilize their configured addresses..."
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.
>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.
I disagree. 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.
>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.
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.
If you agree with my comments and changes, I'll submit an updated
draft-05 for publication in a few days.
Stuart Cheshire <[EMAIL PROTECTED]>
* Wizard Without Portfolio, Apple Computer, Inc.
* www.stuartcheshire.org
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
