Subject: Gen-ART review of draft-cheshire-ipv4-acd-05.txt

From: Spencer Dawkins <[email-masked]>
Date: Fri, 16 Nov 2007 10:40:19 -0600

Hi, Stuart,

I have been selected as the General Area Review Team (Gen-ART) reviewer for 
this draft (for background on Gen-ART, please see 
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments you 
may receive.

Document: draft-cheshire-ipv4-acd-05.txt
Reviewer: Spencer Dawkins
Review Date:  2007-11-14
IETF LC End Date: 2007-11-23
IESG Telechat date: (not known)

Summary: This document is ready for publication as a Proposed Standard.

Comments: Any draft that was added by Steve Coya, was DISCUSSed by Randy 
Bush and Eric Nordmark, and is still active in 2007, has probably simmered 
long enough to be Mostly Harmless :-)

I have some suggestions, but NONE of them should block approval of this 
document.

This draft updates a three-digit-numbered RFC, and a lot of the discussion 
in https://datatracker.ietf.org/idtracker/draft-cheshire-ipv4-acd/ is about 
the archeology of really old ARP implementations. I don't have that 
background, and I'm relying on the INT-AREA review that Mark points out in 
the tracker entry for subtle points that I would have missed.

1. Introduction

...

   The utility of IPv4 Address Conflict Detection (ADC) is not limited
   to DHCP clients.  No matter how an address was configured, whether
   via manual entry by a human user, via information received from a
   DHCP server, or via any other source of configuration information,
   detecting conflicts is useful.  Upon detecting a conflict, the
   configuring agent should be notified of the error.  In the case
   where the configuring agent is a human user, that notification may
   take the form of an error message on a screen, an SNMP trap, or an

Spencer: "an SNMP trap" is still a protocol operation - not sure why this is 
listed under notifying a "configuring agent" that "is a human user". Would 
"an SNMP trap to a management station" be clearer? (I bet that's what you 
were thinking anyway)

   error message sent via text message to a mobile phone.  In the case
   of a DHCP server, that notification takes the form of a DHCP DECLINE
   message sent to the server.  In the case of configuration by some
   other kind of software, that notification takes the form of an error
   indication to the software in question, to inform it that the address
   it selected is in conflict with some other host on the network.  The
   configuring software may choose to cease network operation, or it may
   automatically select a new address so that the host may re-establish
   IP connectivity as soon as possible.

1.1. Conventions and Terminology Used in this Document

   In this document, the term "ARP Probe" is used to refer to an ARP
   Request packet, broadcast on the local link, with an all-zero 'sender
   IP address'.  The 'sender hardware address' MUST contain the hardware

Spencer: It just seems weird to have MUST-strength 2119 requirements present 
in "Conventions and Terminology". If the rest of this section was in its own 
section, that would seem less weird to me.

   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".

   address' field MUST be set to the address being probed.  An "ARP
   Probe" conveys both a question ("Is anyone using this address?")
   and an implied statement ("This is the address I hope to use.").

   The following timing constants are used in this protocol; they are
   not intended to be user-configurable.  These constants are referenced

Spencer: I'm not sure what "user" is being referred to here...

Spencer: A quick look at section 2.2 makes it clear that you're expecting at 
least some of these values to change based on LAN technology 
characteristics - it would be nice to have a sentence pointing this out now 
(more explicitly than "referenced in Section 2").

Spencer: Section 2.2 talks about timeout values that you DO expect to 
change, but some of these are "number of PPP packets" - you might point out 
whether you expect the non-timeout values to change in specific 
deployments/technologies, as well.

   in Section 2, which describes the operation of the protocol in
   detail.

   PROBE_WAIT           1 second   (initial random delay)
   PROBE_NUM            3          (number of probe packets)
   PROBE_MIN            1 second   (minimum delay until repeated probe)
   PROBE_MAX            2 seconds  (maximum delay until repeated probe)
   ANNOUNCE_WAIT        2 seconds  (delay before announcing)
   ANNOUNCE_NUM         2          (number of announcement packets)
   ANNOUNCE_INTERVAL    2 seconds  (time between announcement packets)
   MAX_CONFLICTS       10          (max conflicts before rate limiting)
   RATE_LIMIT_INTERVAL 60 seconds  (delay between successive attempts)
   DEFEND_INTERVAL     10 seconds  (minimum interval between defensive
                                    ARPs).

1.3. Applicability

   This specification applies to all IEEE 802 Local Area Networks (LANs)
   [802], including Ethernet [802.3], Token-Ring [802.5] and IEEE 802.11

Spencer (nit): "Token-Ring" ... wow. Does listing 802.3/5/11 actually add 
information here, beyond 802?

   wireless LANs [802.11], as well as to other link-layer technologies
   that operate at data rates of at least 1 Mbps, have a round-trip
   latency of at most one second, and use ARP [RFC826] to map from IP
   addresses to link-layer hardware addresses.  Wherever this document
   uses the term "IEEE 802", the text applies equally to any of these
   network technologies.

   Link-layer technologies that support ARP but operate at rates below
   1 Mbps or latencies above one second will still work correctly with
   this protocol, but more often may have to handle late conflicts
   detected after the Probing phase has completed.  On these kinds
   of link, it may be desirable to specify different values for the

Spencer (nit): s/link/links/

   following parameters:

   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 an IP
   address that is locally well known and assumed to be relatively
   constant.  For example, the address of the default router is one of
   the parameters that a DHCP server typically communicates to its
   clients, and (at least until mechanisms like DHCP Reconfigure [RFC
   3203] become widely implemented) there isn't any practical way for
   the DHCP server to inform clients if that address changes.
   Consequently, for such devices handling conflicts by picking a new IP
   address is not a good 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

Spencer (nit): this is a very long paragraph. If you broke it into two 
paragraphs, this would be a good place to break it.

   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.

Spencer: this list of ways to inform an operator isn't the same list of ways 
to inform a "configuring agent" that's used in the Introduction, and some of 
the additions here are also applicable to that function (do YOU think the 
two functions are different?). You might consider using the same list in 
each case.

2.2 Shorter Timeouts on Appropriate Network Technologies

   Network technologies may emerge for which shorter delays are
   appropriate than those required by this document.  A subsequent IETF
   publication may be produced providing guidelines for different values
   for PROBE_WAIT, PROBE_NUM, PROBE_MIN and PROBE_MAX on those
   technologies.

Spencer: this ("subsequent IETF publication") makes perfect sense to me, but 
it would be nice to have a sentence in 1.1 that points to this section, so 
people know why other values might be used, and where to look for them.

2.4 Ongoing Address Conflict Detection and Address Defense

...

   (b) If a host currently has active TCP connections or other reasons

Spencer: yeah, this spec has been around a while ... we now have SCTP and 
DCCP that also have connection setup semantics, and they will also break 
during forced address reconfiguration. RTP/RTCP would also count if they 
were established by SIP/SDP, etc.

Spencer: s/TCP/transport protocol/g ?

   to prefer to keep the same IPv4 address, and it has not seen any
   other conflicting ARP packets within the last DEFEND_INTERVAL
   seconds, then it MAY elect to attempt to defend its address by
   recording the time that the conflicting ARP packet was received, and
   then broadcasting one single ARP announcement, giving its own IP and
   hardware addresses as the sender addresses of the ARP.  Having done
   this, the host can then continue to use the address normally without
   any further special action.  However, if this is not the first
   conflicting ARP packet the host has seen, and the time recorded for
   the previous conflicting ARP packet is recent, within DEFEND_INTERVAL
   seconds, then the host MUST immediately cease using this address and
   signal an error to the configuring agent as described above.  This is
   necessary to ensure that two hosts do not get stuck in an endless
   loop with both hosts trying to defend the same address.

...

   Forced address reconfiguration may be disruptive, causing TCP

Spencer: again, s/TCP/transport protocol/...

   connections to be broken.  However, such disruptions should be
   exceedingly rare, and if inadvertent address duplication happens,
   then disruption of communication is inevitable.  It is not possible
   for two different hosts using the same IP address on the same network
   to operate reliably.

2.5 Broadcast ARP Replies

...

   Sending ARP Replies using broadcast does increase broadcast traffic,
   but in the worst case by no more than a factor of two.  In the
   traditional usage of ARP, a unicast ARP Reply only occurs in response
   to a broadcast ARP Request, so sending these via broadcast instead
   means that we generate at most one broadcast Reply in response to
   each existing broadcast Request.  On many networks, ARP traffic is
   such an insignificant proportion of the total traffic that doubling
   it makes no practical difference.  However, this may not be true of
   all networks, so broadcast ARP Replies SHOULD NOT be used

Spencer: slightly confused about why SHOULD NOT, if this is not a problem in 
most cases. Is this stronger (or broader) than it needs to be? Is this an 
implicit recommendation for "if an implementation supports broadcast ARP 
Replies, it SHOULD also include a knob restricting operation to unicast ARP 
Replies, and the default setting SHOULD be 'unicast'"?

   universally.  Broadcast ARP Replies should be used where the benefit
   of faster conflict detection outweighs the cost of increased
   broadcast traffic and increased packet processing load on the
   participant network hosts.

4. Historical Note

...

   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.

Spencer (nit): this isn't true (three years later), but s/are/include/ IS 
true ...

   However, implementers of IPv4 Address Conflict Detection should be
   aware that, as of this writing, Gratuitous ARP is still widely

Spencer: still true in 2007? I assume so, but don't know.

   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. 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 16 Nov 2007 11:59:16 -0600

Sudden burst of insanity - I was interrupted when I was typing this part of 
the review, and now realize that in

> change, but some of these are "number of PPP packets" - you might point 

"PPP" doesn't look like "generic packets" - that's what I meant to say, I've 
NEVER thought ARP had anything to do with Point-to-Point Protocol :-(

I apologize for not snapping when I was typing this.

Thanks,

Spencer

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 22 Nov 2007 16:24:55 -0800 (PST)

On Fri, 16 Nov 2007, Spencer Dawkins wrote:
> 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