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

From: Thomas Narten <[email-masked]>
Date: Tue, 07 Jan 2003 16:07:17 -0500

I hope we aren't losing momentum on completing this draft. Do we have
agreement on what words need to get tweaked in the document?

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

Noted. But this is still a limited experience and is not proof that no
problems can or will arise. For example, Apple clients may be deployed
primarily in certain environments and not appear at all in other
environments. So it is not immediately clear that your experience
translates to "no problems can or will ever arise from these
techniques". I'm not saying this to say this is a bad idea and
shouldn't be done, but just to remind us all that the internet is a
very big place and there are lots of localized environments that we
may not have all that much direct experience in. So we need to be
careful about generalizing experiences.

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

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

It would be better to add the text in the intro/abstract. The header
lines get lost sometimes in the translation to an RFC. Been there,
done that.

Also, how does this spec update 2132? (or do you mean 2131)? Note, if
this document is to update 2131, it needs to:

1) very clearly say what aspect of 2131 it is updating. Right now,
it's not clear what part is being updated.

2) need to be approved by DHC WG.

I actually don't know that this document should be updating the DHC
spec. It's for the DHC folk to update their specs and point to this
one, even if DHC was the motivation (at one level) for the document.

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

How about (at the end of the intro):

    The protocol described in this document addresses a subset of the
    address conflict detection of [v4LL], but is applicable for use
    with other unicast addresses, not just IPv4 link-local addresses.

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

I hadn't really noticed this here, but the document is specifying
behavior related to multiple interfaces, not just one. Traditionally,
ARP is run on a single interface. It's scope is limited to that
interface. 

I'm not sure its necessary or desirable to shift away from that
model. Or what the actual benefits are.

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

Is there really a need to talk about behavior or impacts related to
multiple interfaces? I.e, normally, one runs ARP on a single
interface. When doing  checks about the addresses, one only checks
addresses on the interface on which the ARP packet was actually
received. I.e., if you have an ethernet and a wireless, one runs the
checks indepdently on both.

Does the  current wording stem from assumptions about how ARP is
implement on a particular stack? E.g., one ARP process/module for all
interfaces, as opposed to conceptually different instances on both
interfaces?

In talking with Erik on the phone earlier today, one concern he had
was that having ARP traffic on one interface actually impact what goes
on on other interfaces is a DOS attack that allows an intruder to
impact addresses on links other than just those to which it
connects. One can argue how much of an increased threat this is, but
it is an increased threat. Also, I'm not convinced its necessary for
correctness.

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

My read of the quoted comment is that 2 or 3 seconds, rather than 8 as
the document currently says might be a better default. Or am I
misreading?

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

Again, change the defaults to make the default shorter?  Or at the
very least, more discussion about this (possibly in an appendix)?

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

Maybe point out that if an implementation over ethernet can
distinguish between RSTP and STP BPDU, it should choose timers
intelligently in this case rather than use defaults that would be
suboptimal? The point here is to try and help implementors make good
implementation decision by giving them useful guidance. Maybe this
would be better in an appendix.

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

A user might want to disable the part about ongoing conflict detection
where the node gives up an address, or that it sends out broadcast ARP
responses. There is a tradeoff here in terms of increased bandwidth
vs. faster detection. Not everyone will necessarily weigh the relative
benefits the way you are. You seem to be saying the spec should not
allow or provide for this. There is a difference between detecting at
address config time vs. doing it after the address has already been
used.

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

As has been pointed out on the DHC list, the DHC-specified behavior is
to send out ARP replies, not ARP requests.

While I value your and Apple's experience here, your experience
doesn't necessarily generalize to the conclusion "not useful and not
needed", which is the way your response could be read.

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

Because in *some* environments, the broadcast traffic is more of a
problem than duplicate addresses?

The *conservative* thing to do is to not send out the broadcasts, as
we know that broadcast traffic has caused problems in the past. What
might be good is to have more explanation about the tradeoffs here so
implementors can make an informed opinion. The current text just says
"here are three choices." "pick one".

Some other suggestions:

In the introduction:

>    The authors of the DHCP specification may have thought the answers to
>    these questions too obvious to mention, but unfortunately this leaves
>    some of the burden of protocol design to each individual implementer.
>    This document seeks to remedy this omission by clearly specifying the
>    required actions for:
> 
>    1. Determining whether use of an address is likely to lead to an
>       addressing conflict. This includes (a) the case where the address
>       is already actively in use by another host on the same link, and
>       (b) the case where two hosts are inadvertently about to begin
>       using the same address, and both are simultaneously in the process
>       of probing to determine whether the address may safely be
>    used.

It would be good here to add a couple of sentences saying what the
actual behavior is, per this spec. 

> 
>    2. Subsequent passive detection that another host on the network is
>       inadvertently using the same address. Even if all hosts observe
>       precautions to avoid using an address that is already in use,
>       conflicts can still occur if two hosts are out of communication at
>       the time of initial interface configuration. This could occur with
>       wireless network interfaces if the hosts are temporarily out of
>       range, or with Ethernet interfaces if the link between two
>       Ethernet hubs is not functioning at the time of address
>       configuration. A well-designed host will handle not only conflicts
>       detected during interface configuration, but also conflicts
>       detected later, for the entire duration of the time that the host
>       is using the address.

Again, It would be good here to add a couple of sentences saying what
the actual behavior is, per this spec.

> 
>    3. Rate-limiting of address acquisition attempts in the case of an
>       excessive number of repeated conflicts.

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Jan 2003 16:15:06 -0600

> to send out ARP replies, not ARP requests.

Although the RFC does say to send an ARP request, it appears that there 
are no implementations that actually do this - every implementation 
that does anything at all along these lines sends an ARP reply, 
including the latest Windows (dunno about earlier versions, but no 
reason to suspect they are different).   So while in fact the draft is 
contradicting the RFC, it is not contradicting what is deployed.

Which means that in fact in most network environments the behavior the 
draft is describing is in fact already ubiquitous - it's not just Apple 
clients that are doing this.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 08 Jan 2003 09:16:43 -0500

Hi Ted.

> contradicting the RFC, it is not contradicting what is deployed.

It would be good to bring this up on the DHC list, as Bernie's post
asserting that the wording in 2131 (which says send out an ARP Reply)
was correct was not followed up saying anything like the above. It
would be good to get clarification on what the right thing to do, and
if the wording in the DHC spec needs changing, getting that added to
the list of known updates the spec needs.

> clients that are doing this.

I agree that the sending of ARP requests to "announce" the use of an
address has been widely used. But the specific point I was responding
to was not about that, it was about the use of ongoing conflict
detection.  AFAIK, only Apple is doing this today. Is anyone else
doing this?

Thomas

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 08 Jan 2003 06:48:36 -0800

> address config time vs. doing it after the address has already been

Think about how you would try to explain that to someone who is not
technical...a three paragraph dialog box is not good ;-) Seriously, how do
you deal with a new client that won't accept that it cannot get a desired
address if someone doesn't give up in that situation? Now you have a request
- defend loop that cannot stop, *or* you end up with one machine making
endless ARP broadcasts, *or* you end up with conflicting IPs. The current
conflict detection mechanism does not seem, to my tired eyes, to be
something that will be an eater of bandwidth to the extent this is
necessary, and disabling this would seem to cause more problems than it
solves.

> needed", which is the way your response could be read.

In terms of traffic, there's not going to be a large problem here, and I
think that what Stuart is trying to say is that address conflict detection
is a good thing. Yes, you give up a miniscule portion of your bandwidth, but
you gain serious functionality and ease of use in return. That sounds
acceptable.

> problem than duplicate addresses?

Examples of where this will be a severe problem?

> "here are three choices." "pick one".

More information is always good, but, to turn things around a bit, just
because in *some* environments broadcasts have been a problem, we should not
use them ever?

john

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2003 12:49:25 -0600

> the list of known updates the spec needs.

True.   TBH, though, I don't think the spec needs to be updated - I 
think it's fine.   It's just that all the existing implementations are 
out of spec, in precisely the way described in the draft.

> detection.  AFAIK, only Apple is doing this today. Is anyone else

I think that every BSD unix stack checks, but unlike the Apple stack 
they do not relinquish their IP address when they detect a conflict.   
Instead they just log an error message on the console.   TBH, I prefer 
this behavior, but then, I'm a networking geek.   I'm not sure what the 
right thing is for a non-geek-oriented stack, but I think the Apple 
response may be the best that can be done.   We can't further probe 
with an ICMP Echo request, because we have an IP address conflict.   :'}

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 9 Jan 2003 03:00:09 +0100 (CET)

> contradicting the RFC, it is not contradicting what is deployed.

You seem to agree with Thomas' paragraph yet you inverse request/reply.
I'm confused!

I guess there are two different things in RFC 2131: the probing that
is done to check for a duplicate and the annoucement that the client
is now using the address.
The probing is consistent between RFC 2131 and ACD; an ARP request with
a zero sender protocol address.
But the announcement is different; DHC says broadcast ARP reply and
ACD says to use a ARP request for yourself.

So were you commenting on the probe or the announcement?

  Erik

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2003 22:16:41 -0600

> So were you commenting on the probe or the announcement?

The announcement.   All DHCP clients that I know of do the reply 
instead of the request - i.e., they're out of spec.   :'}

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Jan 2003 17:30:02 +0700

Date:        Wed, 8 Jan 2003 22:16:41 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | > So were you commenting on the probe or the announcement?
  | 
  | The announcement.   All DHCP clients that I know of do the reply 
  | instead of the request - i.e., they're out of spec.   :'}

Ted, I am pretty sure you have read 2131 sometime or other, but as Erik
noted, 2131 says to broadcast an ARP *reply* to announce a new address
has been accepted.    As you note, that is what all DHCP clients do.
This is hardly surprising, as it is also what systems were doing to
announce their use of an address from before DHCP existed (though,
unfortunately for those of us who had to live through it, not from when
ARP was first invented).

So, what's out of spec, other than the acd draft?   (In theory, if everyone
did ARP exactly as specified, the request should also suffice instead of
a reply (though it is a perverse kind of "request") - but in practice,
ARP implementations don't tend to conform exactly to the spec, sending ARP
reply (unsolicited reply) works...)

kre

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Jan 2003 11:29:44 -0600

> has been accepted.    As you note, that is what all DHCP clients do.

Oy.   I've read that text several times in the past couple of weeks, 
but for some reason I still got it backwards.   Sorry about that.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jan 2003 13:53:50 -0600

> instead of the request - i.e., they're out of spec.   :'}

So, just to be clear about my faux pas last week, RFC2131 says to do an 
ARP *reply* to announce that it has its new IP address, but existing 
clients send an ARP *request* with the newly-acquired DHCP address in 
source and destination IP address fields - for example, here's what 
Win98SE transmits (I have a 10baseT switch that filters unicasts, so I 
only got the broadcasts):

13:33:08.865011 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] 
xid:0xea456228 vend-rfc1048 DHCP:REQUEST CID:01:00:03:ff:66:34:0a 
RQ:10.0.1.5 SID:10.0.1.1 HN:"Windows 98SE^@" 
FQDN:0.0.0.87.105.110.100.111.119.115.32.57.56.83.69.0 
VC:77.83.70.84.32.57.56 PR:SM+DN+DG+NS+WNS+WNT+WSC+VO+CLASS (ttl 128, 
id 256, len 346)
13:33:08:925932 arp who-has 10.0.1.5 tell 10.0.1.5

This is what is recommended in the Stevens TCP/IP book.   I think the 
reason this is so common is that the ARP announcement is part of the 
interface configuration process, and is not done by the DHCP client, so 
the people that read the DHCP spec aren't the ones that write the code 
that does the announcement.   This is certainly the case with the ISC 
DHCP client.   On Unix systems of which I am aware, it's not possible 
to do ARP processing outside the kernel.   Since the ISC DHCP client 
runs on Unix, it's pretty much stuck with whatever the operating system 
provides.

So in fact all the DHCP clients of which I am aware are technically out 
of spec with RFC2131.   I don't think this is a big problem, or that 
RFC2131 needs to be immediately updated.   The language in RFC2131 is 
specifying generic behavior that all IP stacks should implement 
regardless of whether or not they support DHCP, and therefore RFC2131's 
recommendation is just that - a recommendation.   So it's actually very 
helpful that Stuart is coming out with a document that's not 
DHCP-specific that states how this should be done, and it's also fine 
that it contradicts the recommendation stated in RFC2131.   I'm not 
sure we need to say that this draft updates RFC2131 - I leave that up 
to those more knowledgable about the IETF process to decide.

---

From: Brad Hards <[email-masked]>
Date: Tue, 14 Jan 2003 07:10:26 +1100

> runs on Unix, it's pretty much stuck with whatever the operating system
It may not be possible on all Unix systems, but it _is_ possible to do general 
ARP processing on many systems. We do this on zcip (http://zeroconf.sf.net), 
which runs in userspace. It does take some BSD type kernel extensions, but 
they are provided by the various BSDs ([free, net, open]) and Linux systems. 
I'm not sure about other unices.

Brad

- -- 
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?

---

From: John Schnizlein <[email-masked]>
Date: Tue, 14 Jan 2003 09:23:57 -0500

I am uncomfortable with the attribution of out-of-spec for DHCP clients.
Since the recommendation (SHOULD) to send an ARP-reply is in the context 
of the client (excerpt below) checking that the offered address is 
actually available, the ARP-request, which you say most clients perform, 
appears perfectly reasonable. Since, without the ARP-request the client 
cannot send a DHCP-decline, it seems the ARP-request is desirable.

In fact, performing both the ARP-request and the ARP-reply avoids the
appearance of an unsolicited ARP on a network segment, which could be an
attempt to steal an IP address. My opinion is that the ARP-announce, 
an ARP-reply without an ARP-request, would be questionable, and 
I was happy to see the ZeroConf specification moving away from it.

RFC 2131  [Page 38 & 39] 
   ... The client SHOULD perform a
   check on the suggested address to ensure that the address is not
   already in use.  For example, if the client is on a network that
   supports ARP, the client may issue an ARP request for the suggested
   request.  When broadcasting an ARP request for the suggested address,
   the client must fill in its own hardware address as the sender's
   hardware address, and 0 as the sender's IP address, to avoid
   confusing ARP caches in other hosts on the same subnet.  If the
   network address appears to be in use, the client MUST send a
   DHCPDECLINE message to the server. 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.

John

At 02:53 PM 1/13/2003, Ted Lemon wrote:
>>The announcement. All DHCP clients that I know of do the reply instead of the request - i.e., they're out of spec.   :'}
>
>So, just to be clear about my faux pas last week, RFC2131 says to do an ARP *reply* to announce that it has its new IP address, but existing clients send an ARP *request* with the newly-acquired DHCP address in source and destination IP address fields ...
>
>So in fact all the DHCP clients of which I am aware are technically out of spec with RFC2131.   I don't think this is a big problem, or that RFC2131 needs to be immediately updated.   The language in RFC2131 is specifying generic behavior that all IP stacks should implement regardless of whether or not they support DHCP, and therefore RFC2131's recommendation is just that - a recommendation.   So it's actually very helpful that Stuart is coming out with a document that's not DHCP-specific that states how this should be done, and it's also fine that it contradicts the recommendation stated in RFC2131.   I'm not sure we need to say that this draft updates RFC2131 - I leave that up to those more knowledgable about the IETF process to decide.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Jan 2003 23:56:19 -0600

The text there says that the client should send the ARP *request* to 
check for a conflict.   The ARP request is supposed to use an IP 
address of 0.0.0.0 as the sending station's IP address, so as to avoid 
asserting that the sending station has the assigned IP address.   Only 
after this ARP request has failed to identify a conflict does the 
client send a message asserting that it has the IP address it has been 
assigned.   So the client sends two ARP packets - an ARP request and an 
ARP reply.

What the proposed draft does is to change the recommended behavior for 
asserting an IP address using ARP so that this is done with an ARP 
request rather than an ARP reply.   You should take a look at the 
zeroconf mailing list archives to see Stuart's proposed text that 
explains why this is the right thing to do.   I'm sorry that some of 
this stuff got cross-posted to DHCwg and some didn't, so that you don't 
have the full context.   This whole thing is _very_ confusing, so it's 
a really good thing that Stuart is trying to clarify it.   :'}