IPv4 Address Conflict Detection
RFC 5227

 Issues with draft-cheshire-ipv4-acd-02.txt

 High-order bit: the probing and annoucement part seems like very
 useful things to standardize. But the ongoing conflict detection (causing
 IP address change when a conflict appears) and broadcast replies looks
 more like a useful experiment to me.

 Also, the timeouts claim to be related to IEEE 802.1D behavior doesn't
 match IEEE 802.1D reality. (See below)


 Specfic comments:
 The document is written as if it updates RFC 826 and DHCP (RFC 2132) but
 it doesn't explicitly say this.

 > 3. Rate-limiting in the case of an excessive number of repeated
 > conflicts.

 Would be helpful to say what is rate limited; the attempt to use
 a different address (and not e.g. the rate at which some packet is sent)

 > This document standardizes the widely-used natural interpretation of
 > an ARP Request where the Target Protocol Address is non-zero but the

 While this might be natural, I have no idea whether or not it is widely
 used. Wants me want to ask for the survey results of 50 ARP implementations
 and how they do this.

 > This document standardizes the widely-used natural interpretation of
 > an ARP Request where the Sender and Target Protocol Address fields
 > contain the same address, namely that it is an assertion without an
 > associated question (an "ARP Announcement").

 Same general question as above, except that there is another
 natural case - that an ARP Reply where the sender and targer
 are the same. Given that ARP is widely implemented it would be
 useful to understand 1) to what extent implementations do
 announcements using requests or replies, and depending on that answer
 2) whether the protocol could allow both forms of annoucements i.e.
 any packet with equal sender protocol address and target protocol address
 would be an announcement.

 > "Dynamic Configuration of IPv4 Link-Local Addresses" [v4LL] can
 > benefit from this optional capability.

 The "can benefit" is odd since it looks like a suggestion to
 fix v4LL to do this, when in fact it already does.
 It is perhaps better to have some statement up front that this
 protocol is a subset of the address conflict detection of v4LL.


 > RFC 826 implies that replies to ARP requests are usually delivered
 > using unicast, but it is also acceptable to deliver ARP replies using
 > broadcast. The "Packet Reception" rules in RFC 826 specify that the
 > content of the "ar$spa" field should be processed *before* examining
 > the "ar$op" field, so any host that correctly implements the Packet
 > Reception algorithm specified in RFC 826 will correctly handle ARP
 > replies delivered via link-layer broadcast.

 I think there are implementations of RFC 826 which do not follow
 the pseudo-code in RFC 826. What do we know about the effect
 of broadcast arp replies on them? 
 For example, I looked at the Solaris ARP code and it treats
 a broadcast arp reply as an ARP announcement which, due to the structure
 of the implementation, incurs more processing overhead than a ARP
 packet which is not considered to be an announcement.
 I wouldn't be surprised if there are other surprising behaviors related
 to broadcast ARP replies.

 > server, etc.) that the proposed address is not acceptable. 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
 > any of the host's interfaces, 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

 The above is the only place where multihoming comes into the spec by 
 mentioning "any of the host's interfaces". I would assume that ACD can 
 operate independently for each interface even though v4LL has some 
 extra stuff related to multi-interface nodes.

 Section 2.2 on timeouts seems to not work.
 The 802.1d standard suggests default timers which result in it
 taking about 30 seconds until a switch port passes traffic after
 it has been enabled. I've personally observed more like 45 seconds
 when my office Ethernet drop has had spanning tree protocol enabled.

 But in most cases this isn't needed. When DHCP is used (whether it is
 a desktop machine or some portable handheld wireless device) then
 no DHCP will happen until the switch starts forwarding packets.
 And the link-local case is handled in the v4LL specification.
 This leaves manually configured addresses.
 If you take into account that IEEE 802.1 is rapidly moving to
 obsolete spanning tree protocol in favour of the rapid spanning tree
 protocol, I don't see benefit in making the DHCP clients take 30-45
 seconds longer to initialize the stack just because that might be
 the conservative number for manually configured IP addresses until
 RSTP is deployed.
 And this calls into question the 4 packets spaced 2 seconds apart - 
 perhaps 1 or 2 packets are sufficient if you assume that the L2 is 
 forwarding frames by the time the ACD protocol runs.

 > (c) If a host has been configured such that it should not give up its
 > address under any circumstances, perhaps because it is an important
 > company server with a well-known IP address, then it MAY elect to

 company vs. university vs. home server presumably doesn't matter.
 s/company//
 It isn't "well-known" (as in potentially hard-coded in applications)
 that matter. Instead it is the assumption that the address be 
 temporarely stable because of long running connections and/or it being 
 in the DNS with a longish DNS TTL, that matters here.

 Section 2.5 on broadcast arp replies
 has a MAY and goes it to say that they should not be used universally.
 I think the MAY refers to MAY implement. In order to be able to
 operationally control the use I suspect it needs to be more strict
 and e.g. say "MAY be implemented. When implemented, there MUST be a 
 knob to enable the use of broadcast arp replies, and this knob MUST 
 default to false" or something similar that gives control on the *use* 
 of this.

 Finally, references should be split between normative and non-normative
 per rfc-editor policy.

Section 1.2.1 et seq refer to "the widely-used natural interpretation
of" a particular kind of ARP packet not explictly described in the ARP
specification (NB: I have not verified that this packet isn't
described in the ARP spec, I'm taking the author's word on this point
for the moment). Alarm bells here, there are enough independent ARP
implementations that this is almost certainly a statement of the
author's opinion rather than a testable fact. Does this play well
with, eg, the ARP code in your PDA? The boot ROM in your cable modem?

Section 1.2.3 suggests that broadcasting ARP responses is a good
thing. I have always viewed it as a necessary evil used primarily to
kludge around implementation issues for programs like DHCP servers on
operating systems that lack a mechanism by which the DHCP server can
stuff the ARP cache prior to responding when allocating an address.
Anything that encourages more broadcasts without a damned good reason
makes me nervous. I could be wrong, of course, but paranoia about
broadcast has served me well in the past (I was pretty sure that the
default setting required by RFC 1812 5.3.5.2 was a bad idea long
before Smurf attacks justified my paranoia).

I see no mention of DHCP relays anywhere in the document. Not
particularly relevant to the author's presumed main purpose (conflict
detection for IPv4 link local addresses), but since the document
mentions DHCP extensively it probably ought to mention that DHCP is
sometimes used in ways for which this mechanism won't help much.

I have not figured out yet whether the timing parameters in section
2.1 make this mechanism prone to synchronized broadcast storms. The
use of fixed length intervals after the initial random wait will keep
probes in step if they start out in step, the question is whether the
initial random wait is enough to avoid syncronized probes. To be
fair, if assume that the initial random wait is not sufficient, we may
be saying that we don't trust the random number generator being used
by the machines performing the probes, in which case the usual
solution (add some random jitter each time) may not help. So maybe
this is just a requirement that implementations had damned well better
be able to do the initial random wait properly (which may beg the
question of seed material on deeply embedded devices).

In view of my misgivings about section 2.1, the suggestion of much
shorter fixed timeout intervalss on wireless networks in section 2.2
does not improve my comfort level.

I have a vague memory that the step described in section 2.3
(so-called "gratuitous ARP") was considered somewhat controversial at
one point, but I no longer remember why unless it's just dislike of
the mandatory delay.

Section 2.4 doesn't worry me as much as the earlier sections. The
proposed mechanism for active defense seems like a fairly reasonable
way of handling a situation that is already demonstrably broken.
Note, however, that in pathological cases this mechanism could be used
as a means of triggering broadcast storms (trick a bunch of machines
into using the same address, then broadcast a packet that will make
them all try to defend it at once). I don't think this is a serious
risk, but something about it probably belongs in the security
considerations section.

Section 2.5 is more of the same optimism about broadcast ARP replies.
I've already commented on that, so I won't belabor the point.

Security Considerations section seems anemic. Aside from the specific
minor issue mentioned above, there's the general issue that this is a
mechanism by which an attacker can send packets via an unsecurable
protocol that will provoke a host to respond in predictable ways.
This is always a bit of a concern, and it's more of a concern with
broadcast protocols.