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