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

From: Stuart Cheshire <[email-masked]>
Date: Fri, 13 Dec 2002 18:45:26 -0800

At last, a reply that actually relates to the subject line.

>> > 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?

There is no data. That's the point. After shipping millions of machines 
per year for five years, the number of reported problems is zero.

>How about adding
>	This document updates RFC 826 and RFC 2132.

I added a header line that says "Updates: 826, 2132"

>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.

Stevens describes using ARP request.
BSD broadcasts an ARP request to announce its address.
Mac OS 9 broadcasts an ARP request to announce its address.
Mac OS X broadcasts an ARP request to announce its address.
Windows broadcasts an ARP request to announce its address.

RFC 2131 describes broadcasting an ARP reply, but like many things in RFC 
2131, this is probably a typo. As has been pointed out many times by many 
people, broadcasting an ARP reply is unconventional, and best avoided 
where not necessary. Therefore I avoided it and followed the behaviour 
described by Stevens (and implemented on Mac, Windows, Unix, etc.) 
instead.

In any case, the "Packet Reception" rules of RFC 826 are exceedingly 
clear that checking the packet opcode is the *last* check that is done, 
after all other packet processing has been completed.

Do you have a technical opinion to offer about which you think is best?

>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.

There is already a non-normative reference to the v4ll draft.

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>>    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
>
>I fail to find the word "multihoming" or any explicit mention of
>multiple interfaces in the above text.

The phrase, "any of the host's own interface addresses" is a mention of 
multiple interfaces.

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>> > 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?

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>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.

The document already has specific text allowing shorter timeouts in cases 
where the implementer has reason to believe that is a wise design choice.

The document already has specific text describing how the individual 
choice of timeout doesn't have any impact on interoperability with other 
devices.

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>> 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.

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

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

Quoting from Mick Seaman: "Yes, the driver can easily tell the difference 
between an RSTP and an STP BPDU, they are different 'BPDU types', a type 
field being defined in the BPDU format."

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>> 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.

I don't understand why you think there is a problem.

DHCP clients have done address conflict detection for years, and no one 
has asked for an option to disable address conflict detection there.

Macs have done address conflict detection for manual addresses for years, 
and no one has asked for an option to disable that either.

Even Windows tells you if you manually set your IP address to an address 
that's already in use.

If you've ever struggled with a network where two machines were set to 
the same IP address, you'd think it insane to ever think you'd NOT want 
to get all the help you can to diagnose and fix that problem.

I don't understand why now, after all these years of successful address 
conflict detection that no one ever complained about, there's suddenly a 
feeling that we need manual configuration options to disable it.

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Dec 2002 23:53:54 -0500

I don't have any inherent problems with the idea of using ARP
for address conflict detection; as Stuart indicates, this has been
widespread practice for years and few problems have been noted.
I don't even see a need to have an option to disable conflict
*detection*.  However some of the actions recommended in the
draft for dealing with conflict detection should definitely NOT 
be enabled by default.

However this draft's recommendations go somewhat beyond widespread 
practice, or at least such practice as I've observed:

- Broadcast ARP replies.  I agree that the ARP spec is fairly
  clear about handling of ARP replies, so I think the potential for
  this confusing host stacks is small.   My concern is that broadcasts 
  add extra network traffic and load on hosts, especially if some hosts
  periodically ARP for their own addresses (for a variety of reasons:
  perhaps they do this each time they renew a DHCP lease, perhaps
  the host is periodically rebooted, perhaps the implementor thought
  that periodic active address defense was a good idea)

  I recommend that unicast ARP replies SHOULD be the default.  broadcast 
  ARP replies SHOULD be optional to implement, and if implemented, 
  SHOULD require explicit configuration to be enabled.

- The idea that a host may give up its address, and that it needs
  a good reason to keep that address, is a significant departure
  from longstanding practice.   Many protocols layered on top of 
  IP (and not just those using TCP) expect IP address-to-host bindings
  to be reasonably stable.   

  The current text seems to encourage hosts to treat addresses as
  temporary unless explicitly configured to treat them as
  permanent.  This would be a significant departure from the IP
  architecture and an extremely harmful change; so I strongly urge that
  this text be reworded.

Documenting and standardizing use of ACD seems like a good idea.  
However this document seems to suffer from trying to justify design decisions 
made for the link local proposal.  IMHO it would be more constructive to 
treat use of ACD for v4LL as an exception to the normal behavior than to 
treat it as an example of normal behavior.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 14 Dec 2002 11:28:47 -0500

>   architecture and an extremely harmful change; so I strongly urge that

Um...having had to deal with a statically configured network when a small
device went insane, and started grabbing other IP addresses, and neither
side gave up on the fight, the option for the 'elder' device to cede to the
'younger' device in the event that the younger device won't give up on its
insane quest for the one address is *a good thing*...that way, you only have
one device with a temporary problem, not many with a problem that isn't
fixable on its own.

Also, as is noted, you may have cases where previously separate links become
joined, via a bridge. At that point, you have multiple address conflicts
between multiple devices, all with the same level of seniority. Without a
procedure that handles this gracefully, then you have multiple machines that
will require a manual reset of some sort. This of course, would be *a bad
thing*.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM