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

[Spencer Dawkins <spencer at mcsr-labs.org>]

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
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf