[dhcwg] FWD: Re: IESG draft-cheshire-ipv4-acd-02.txt

[Thomas Narten <[e-mail]>]

Anyone care to comment on the assertion below regarding a typo in 2131?

Thomas
- ------- Forwarded Message

From: Stuart Cheshire <[e-mail]>
To: "Erik Nordmark" <[e-mail]>
Cc: <[e-mail]>
Date: Fri, 13 Dec 2002 18:45:26 -0800
Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt

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 <[e-mail]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * Chairman, IETF Zeroconf
 * www.stuartcheshire.org

- ------- End of Forwarded Message

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