[Gen-art] Re: Gen-ART review of draft-cheshire-ipv4-acd-05.txt

[Carlos Pignataro <[e-mail]>]

[cc to iesg only as this was discussed already [2]]

I find this document *very* useful, please find however a small
question/comment regarding the ARP Announcement. The document mentions that:

   Gratuitous ARP is the exact same packet that this document refers to
   by the more descriptive term "ARP Announcement".

But there is the old split on whether to announce (grat arp) using
request or reply opcode (which is pointless to debate). However, given that:

1. Some OSes implement grat arps with Request ar$op, others with Reply.
2. Some literature uses Request (Stevens), other Reply (Comer).
3. Some RFCs use Reply for ARP Announcement, others Request [1].
4. The semantic part of the processing for the announcement on
   receipt happens before checking the opcode, so ultimately it wouldn't
   matter.

The Q: To provide some sort of backwards-compatibility, and while a
receiver would correctly parse and interpret the "ARP Announcement" for
either opcode (no interop problems), would it be sensible to allow for
either opcode in ARP Announcements? i.e., allow an "ARP Announcement"
with equal sender and target protocol addresses, regardless of the
opcode. Or at least to SHOULD send but a robust receiver does not care
the opcode?

[1]
RFC2131 (DHCP) says:
	"The client SHOULD broadcast an ARP reply to announce the
	client's new IP address and clear any outdated ARP cache entries
	in hosts on the client's subnet."
draft-ietf-mobileip-protocol-14:
	"A Gratuitous ARP is an ARP Reply that is sent without having
	been prompted by the receipt of any ARP Request.  The ARP Reply
	is..."
RFC2002 -> RFC3220 -> RFC3344:
	"A gratuitous ARP MAY use either an ARP Request or an ARP Reply
	packet."
RFC3768:
	"Broadcast a gratuitous ARP request..."

[2]
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg03799.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg00669.html

Thank you,

--Carlos.

On 11/16/2007 11:40 AM, Spencer Dawkins said the following:
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art