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 "PPP" doesn't look like "generic packets" 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.