IPv4 Address Conflict Detection
RFC 5227

THESE DISCUSSES AND COMMENTS ARE COPIED FROM THE OLD TEXT STYLE BALLOT (IESG circa 2002):

DISCUSS
=======
Randy:

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.

Erik:

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.


COMMENT:
========
Scott:
note:
                references not split

[Note]: 'Back on the agenda so I can be sure there are no more discusses, and if enough positions have been recorded. The text ballot is broken.
This is for version -06 which should arrive in the repository soon. Otherwise, you may find it here: http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-06.txt' added by Mark Townsley

[Note]: 'Sent email to Erik and Stuart about old DISCUSS positions and, in particular, comments from Erik about Sun''s implementation. Also asked Bernard and Stuart to follow up on CM Heard''s LC Comment. Awaiting responses.' added by Mark Townsley

[Ballot discuss]
I am not sure what rules apply to this document. From the tracker I am pointed not to the current ballot page, but rather to the older page which dates a few years and a few IESGs back - http://www.ietf.org/IESG/EVALUATIONS/draft-cheshire-ipv4-acd.bal

I see there two DISCUSSes that seem to be unresolved. I am holding this DISCUSS until this procedural question is resolved.

I would also be interested whether the issues raised by Randy Bush in his DISCUSS were answered and solved by the more recent versions of the document, or if they are considered to be non-issues why.

secdir review


I am reviewing this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments. Feel free
to forward to any appropriate forum.

The document updates RFC 826 by specifying ways in which
IPv4 addresss conflict detection can be improved.

The document is clear and I can see no new security considerations
that aren't covered that need correcting (though there may
be some, this isn't my area).

The security considerations say that this specification "makes
this existing ARP vulnerability no worse, and in some ways
makes it better" (which I don't doubt), but gives no reference
for the "existing ARP vulnerability." Such a reference would
be useful.

I wondered if some mention of pseduowires [1] might be useful,
but don't know enough to make a sensible suggestion. In principle
one might want some tweaks to the applicablity discussion in
section 1.3.

I also wondered whether there should be some mention of IPsec,
but can't think of anything pressing.

There is a typo on page 3: s/ADC/ACD/

Stephen.

[1] http://www.ietf.org/html.charters/pwe3-charter.html

IETF Last Call Comment

Please consider the following as last-call comments on the above
document.

---------- Forwarded message ----------
Date: Thu, 22 Nov 2007 16:24:55 -0800 (PST)
From: C. M. Heard
To: ietf@ietf.org
Cc: Spencer Dawkins ,
    Stuart Cheshire ,
    GeneralAreaReviewTeam
Subject: Re: Gen-ART review of draft-cheshire-ipv4-acd-05.txt

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

[Note]: 'This ID has been in in need of a revision for more than a year now. Given the length of time, a new IETF LC would be appropriate prior to having the IESG consider the document once a revision appears. I''d like to see this document go forward; it contains good stuff, and we are *so* close to being done.' added by Thomas Narten

[Ballot discuss]
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.

[Ballot discuss]
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.

State Changes to New Version Needed (WG/Author)                    from Pre AD Evaluation                                by narten