Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt

From: Erik Nordmark <[email-masked]>
Date: Fri, 13 Dec 2002 03:34:40 +0100 (CET)

> > But the ongoing conflict detection (causing
> > IP address change when a conflict appears) and broadcast replies looks
> > more like a useful experiment to me.
> 
> It has been a five-year experiment by Apple.

Do you have a pointer to the data that has been collected as part of that
experiment?

> > The document is written as if it updates RFC 826 and DHCP (RFC 2132) but
> > it doesn't explicitly say this.
> 
> I am willing to accept specific text.

How about adding
	This document updates RFC 826 and RFC 2132.
at the end of the abstract and the end of the introduction.

> > > This document standardizes the widely-used natural interpretation of
> > > an ARP Request where the Target Protocol Address is non-zero but the
> >
> > While this might be natural, I have no idea whether or not it is
> > widely used. Wants me want to ask for the survey results of 50 ARP
> > implementations and how they do this.
> 
> This is the interpretation required by DHCP (RFC 2131), so I would hope 
> it is widely used, at least to the extent that DHCP clients are widely 
> used.

You're right. Thanks.

> > Same general question as above, except that there is another
> > natural case - that an ARP Reply where the sender and targer
> > are the same. Given that ARP is widely implemented it would be
> > useful to understand 1) to what extent implementations do
> > announcements using requests or replies, and depending on that answer
> > 2) whether the protocol could allow both forms of annoucements i.e.
> > any packet with equal sender protocol address and target protocol address
> > would be an announcement.
> 
> This is the interpretation described in Stevens (TCP/IP Illustrated, 
> 1994) under the name "Gratuitous ARP" and described as being widely used 
> at that time.
> 
> It is also required by RFC 2131.

RFC 2131 actually talks about an ARP reply and not the ARP request
with sender=target. See section 4.4.1 in RFC 2131.
So you don't seem to be consistent with RFC 2131.

> > It is perhaps better to have some statement up front that this
> > protocol is a subset of the address conflict detection of v4LL.
> 
> I would rather the merits of this document be considered alone, without 
> normative reference to other unpublished specifications.

I wasn't suggesting a normative reference; that isn't needed since the
document is self-contained. But pointing out the relationship using a
non-normative reference to draft-ietf-zeroconf-ipv6-link-local would be useful 
for the implementors that are going to implement both.

> > The above is the only place where multihoming comes into the spec by 
> > mentioning "any of the host's interfaces".
> 
> No, it is also mentioned in 2.4:
> 
>    Address conflict detection should not be limited to only the time of
>    initial interface configuration, when a host is sending ARP probes.
>    Address conflict detection is an ongoing process that is in effect
>    for as long as a host is using an address. At any time, if a host
>    receives an ARP packet (request *or* reply) where the 'sender IP
>    address' is the host's own IP address, but the 'sender hardware
>    address' does not match any of the host's own interface addresses,
>    then this is a conflicting ARP packet, indicating some other host
>    also thinks it is validly using this address.

I fail to find the word "multihoming" or any explicit mention of
multiple interfaces in the above text.

> > I would assume that ACD can 
> > operate independently for each interface even though v4LL has some 
> > extra stuff related to multi-interface nodes.
> 
> No, the specification needs to deal with the case when a host has two 
> interfaces (say wireless and Ethernet) on the same link.

And you claim you can't do that by having the interfaces be configured
independently of eachother?

> > Section 2.2 on timeouts seems to not work.
> > The 802.1d standard suggests default timers which result in it
> > taking about 30 seconds until a switch port passes traffic after
> > it has been enabled. I've personally observed more like 45 seconds
> > when my office Ethernet drop has had spanning tree protocol enabled.
> 
> We live in a world of gigabit Ethernet and gigahertz processors. The days 
> when people were willing to wait 30 seconds for their television set to 
> "warm up" are behind us. We need to provide computers and network devices 
> that can meet the same customer expectations.

I think my conclusion was that the time should be shorter
than 8 seconds and not longer. 8 seconds is a useless compromise
as far as I can tell since it is unecessarily long when STP isn't triggered
and too short when STP is triggered (with out of the box bridge
configurations.) Thus 2 or 3 seconds should be fine.

> Most network operators today, with good reason, set their port blocking 
> time to five seconds.

Doesn't match my experience. And doesn't match the IEEE 802.1D recommendation.

> I am also working with the IEEE 802 committees on an update to rapid 
> spanning tree that allows a host to reliably determine when link 
> connectivity has been established, within 2.5 seconds of connection. When 
> a Mac determines that it is connected to one of these newer switches, and 
> confirms that proper link connectivity has been established, it will then 
> start probing using the shorter timeouts given in Section 2.2.

Is there a way for the host to reliably detect whether the switches run RSTP 
instead of STP?

> A Zero Configuration device may want to make use of address conflict 
> detection. If address conflict detection requires a mandatory 
> user-configuration option, then that means that Zero Configuration 
> devices require mandatory user-configuration options, a 
> self-contradiction.

I'd understand that comment if it was about draft-ietf-zeroconf-ipv4-link-local
but not about the ACD document. Since the addresses are configured either
manually or by DHCP (or some other provisioning protocol) it is possible to
add a knob in the manual config or in DHCP, respectively. So I don't
understand the issue your are concerned about.

  Erik

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 17 Dec 2002 12:17:06 -0800

>I've been making technical arguments for months.  I'm fed up with
>having to respond to completely bogus assertions like

Keith,

I'm willing to give you the benefit of the doubt, and assume that you do 
have some valid technical point(s) to make, but the fact is that you have 
been unable to present them in a way that is comprehensible to anyone 
else.

We need to resolve this problem.

What I suggest is that you think about the technical suggestions you 
have, pick the one that you feel is most important, and create an email 
describing that suggestion. Give the email a descriptive subject line. 
Keep the email short and to the point. Avoid rhetoric and name-calling. 
Avoid making unsubstantiated assertions, or expressions of subjective 
personal opinion that will immediately be shot down or disputed by others 
on the list.

The group will then discuss the suggestion that you have made, and arrive 
at a consensus about it.

When that is done, you can make your next point, and we will repeat until 
all your points have been discussed, or the working group decides that 
this course of action is not yielding productive results.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * Chairman, IETF Zeroconf
 * www.stuartcheshire.org