Subject: Re: hypocrisy of zeroconf

From: Keith Moore <[email-masked]>
Date: Sun, 01 Sep 2002 22:01:01 -0400

> There is nothing about the zeroconf proposals that "redefines IP to
> work differently than applications expect". An application that uses IP
> can continue to transparently do so with an IPv4 link local address
> without knowing the difference. 

this is simply false.

normal IPv4 addresses have global scope and can be used in referrals
without the application having to be aware of network topology.

normal IPv4 addresses are globally unique and can be addressed
without the application having to worry about which network
interface to use.

normal IPv4 addresses do not become invalid at a whim (absent device
failure).

applications that treat IPv4LL addresses like they are normal addresses
will fail for unexpected reasons when those apps try to use them in
referrals to devices on other interfaces or other links, and when those
addresses suddenly stop working due to conflicts.

but you knew this already.  

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Sun, 1 Sep 2002 22:47:07 -0400

>> without knowing the difference.

No, it's conditionally false, or true, depending on how you look at it. 
Depending on the network in question, this will work. Or, it will not. 
But there is nothing in zeroconf that breaks IPv4.

> without the application having to be aware of network topology.

partially correct. Normal IPv4 addresses have whatever scope the 
network they are on chooses to allow them to have. There is no 
requirement for IPv4, or IPv6 for that matter to have (physical) global 
scope. They need scope in relation to the job at hand for the device. 
For example, a printer that is only used by a small group of people 
only needs scope on that scale. It does not need to have it's own 
world-wide address. There are many networks that, for various reasons, 
don't need world-wide scope for their addresses.

This is one of the things that is causing a perceptual problem with 
Zeroconf. Address scope. If you work in a situation where ever IP 
address must have (physical) global scope, then Zeroconf potentially is 
a real problem. However, in many situations, and the majority of 
corporate situations, this is not the case.

IP addresses are private, and the only external Internet access is 
carefully limited and monitored. So for these situations, the 'normal' 
mode for IPv4 addresses are immaterial, as access to the rest of the 
world on a constant or casual basis is neither desirable or allowable. 
In these situations, Zeroconf is almost completely positive in 
potential.

> without the application having to worry about which network

They *can* be globally unique. They don't have to be. They only have to 
be unique for the scope of use.

> normal IPv4 addresses do not become invalid at a whim (absent device

DHCP lease expirations without a renewal invalidate IP addresses.

> addresses suddenly stop working due to conflicts.

In cases where this is not appropriate, there is nothing in Zeroconf 
that prevents you from using other methods of IP address assignment. 
Indications to the contrary are incorrect. Zeroconf is not a binary 
standard. It is designed to co-exist with other network setups. IPv6 
and v4 are able to coexist on the same network, despite being radically 
different in many ways. The same holds true for Zeroconf.

john

---

From: Ian Lister <[email-masked]>
Date: Mon, 2 Sep 2002 13:16:40 +1000 (EST)

>without the application having to be aware of network topology.

This statement is false. RFC 1918 has been around for quite some time now.
NAT is related and certainly broke a few applications, but that's very
different from non-global addressing (and people who use it find the
benefits far outweigh the drawbacks). Do you have similar problems with
RFC 1918?

>without the application having to worry about which network

The first part of this statement is also false (because RFC 1918 already
stops addresses from being globally unique). The second part of this
statement is misleading because IPv4LL addresses will not start breaking
applications on multihomed hosts. Section 3 of the draft covers this issue
in detail, and the only case in which applications might need extra
knowledge about how interfaces relate to addresses is the third case, in
which APIs are updated to explicitly deal with the issue. The requirement
to update existing applications is explicit and any implementor choosing
this path would be fully aware of that need. (FWIW I can't see anybody
choosing that path for an existing platform with substantial existing
applications).

>normal IPv4 addresses do not become invalid at a whim (absent device

Although the definition of `whim' might be open to debate, I think this
statement is largely false too. DHCP made it explicit that addresses can
change (and the application sees it as a whim[0]). Even before that, users
could (and still can) change their address manually (at a whim, or for
some other reason). Some popular platforms used to demand a reboot when
this happened (often the subject of ridicule from people using systems
that were quite happy to change addresses at a whim with no ill effects),
but I'm not aware of any that still do. The worst case is just that an
existing connection is broken and the application has to reestablish it.
Given the low frequency with which this is likely to occur (it requires
two hosts who have already successfully claimed and started using the same
address - about 1 in 2^16 probability - to begin seeing each others'
frames) it puts it in the same category as DHCP leases expiring and users
manually renumbering. Address change has been happening for a long time
and applications that don't deal with it are already broken. IPv4LL
doesn't change this.

>addresses suddenly stop working due to conflicts.

Do you have any examples of applications that will break like this? To
refer to the theme of earlier discussion, having conducted your analysis
and found alleged flaws, can you construct a realistic test case in which
those flaws are exposed?

Do your applications that might be broken by this work with DHCP, RFC
1918, and/or manual readdressing (not to mention NAT)?

Do you think that even if such applications do exist their inability to
correctly function on IPv4LL networks should prevent IPv4LL from being
used at all, regardless of whether its users want to use these
applications or not?

Would (any of) your concerns be satisfied if the draft described the
(currently implemented and widely deployed) behaviour of assigning an
IPv4LL address iff no other address was available (rather than its current
recommendation of assigning IPv4LL regardless of existing addresses).

>but you knew this already.

We've been told it a lot of times, but still haven't had the evidence
presented.

Ian

[0] Unless it has been querying the OS to check on the duration of a
    lease. Of course an IPv4LL implementation can provide support for such
    behaviour by simply reporting its address as being from a very short
    lease.

---

From: Keith Moore <[email-masked]>
Date: Sun, 01 Sep 2002 23:54:32 -0400

> This statement is false. RFC 1918 has been around for quite some time now.

RFC 1918 is intended for private networks - that is networks that
are disconnected from the Internet.  RFC 1918 addresses don't cause any
problems with referrals for such networks because it's impossible for
addresses to leak out of a disconnected network.  NATted networks are
a completely different matter, of course, and NATs do cause problems -
but they cause problems regardless of whether or not they use RFC 1918 
addresses.

> stops addresses from being globally unique). 

again, if you're on a disconnected network, then a RFC 1918 address is
already unique within that network, so it's no problem.   similarly,
if people want to use IPv4 LL addresses on completely disconnected
network, I have no problem with that either.  OTOH the imposition
of IPv4 LL addresses onto networks that are connected to the public
internet (or to other networks) does cause problems for applications.

> The second part of this
> applications on multihomed hosts.  

false.  if an app resides on a host that has multiple interfaces that
support LL addresses, the host in general has no idea which interface
to use to contact an LL address, and it's possible that the same LL
address is available on multiple interfaces.  The idea that the host
can get the interface from the connection state isn't a general solution-
it only works for incoming traffic and for conneciton-oriented protocols.

I haven't reviewed the latest draft (will do so before the end of 
Last Call) but basically there's no way to fix this problem and still
be compatible with existing APIs.  So yes, this is a fundamental change
to the way that IP works, and yes, it will break applications that
are unfortunate enough to encounter duplicate addresses.

> change (and the application sees it as a whim[0]). 

The fact that you can break a network by misconfiguring a DHCP server is 
not a license for the zeroconf WG to break it in other ways. 

> Even before that, users
> could (and still can) change their address manually 

yes, and they can turn off their workstations, or unplug them from
the network, or hit them with sledge hammers.  but we never have expected
the network or applications to recover from such failures.  Linklocal
is forcing new failure modes on essentially every host on the internet
and expecting applications to recover from such failures.

> The worst case is just that an

false.

it's simply incorrect to assume that such failures are recoverable.
in general, there is no other name by which the peer process can reliably 
be contacted, and for many applications successful recovery from broken 
connections requires explicit support in the application-level protocol.

> frames) 
> it puts it in the same category as DHCP leases expiring and users
> and applications that don't deal with it are already broken. 

false.  essentially zero existing applications can transparently recover
from address changes, and the current Internet architecture doesn't provide 
enough hooks to allow applications to do so in general.  there's no other 
reliable name for a peer socket/process than address+port.  

> Do you have any examples of applications that will break like this? 

yes.  pvm.  netsolve.  globus.  

> 1918, and/or manual readdressing (not to mention NAT)?

so what you are saying is that because DHCP and RFC 1918 and NATs are
sometimes misused, that this group has the right to force everyone to
accept the same failure modes that result from misuse of these other
technologies?

> used at all, regardless of whether its users want to use these

let's take two separate cases:

a) is this sufficient for proposed standard?
   I want to read the latest draft just to be sure, but based on earlier
   drafts, I don't think so.  It has known technical deficiencies with
   respect to the reqiurements placed on it.

b) should users be able to use this if they want to?
   sure, but it shouldn't be forced on their hosts and applications, and
   it shouldn't be used on connected IP networks - at least, not without
   some way to keep it from interfering with apps that aren't equipped
   to deal with it.  by all means, use it in disconnected networks.    

> recommendation of assigning IPv4LL regardless of existing addresses).

yes.  the behavior of earlier implementaitons was far preferable to
what the current recommendation requires.

> We've been told it a lot of times, but still haven't had the evidence

no, it's been presented multiple times - there's just a lack of willingness 
to accept it because it illustrates fundamental problems with v4 linklocal
addresses that are not easily fixed.

Keith

---

From: Joshua Graessley <[email-masked]>
Date: Mon, 2 Sep 2002 00:23:36 -0700

> without the application having to worry about which network

As John Welch pointed out, this is false. Private addresses are often 
used and they are often used with NATs. NATs do break a lot of software 
but the simple fact is that enough people have NATs that if your 
software doesn't work with a NAT, your software can not be widely 
deployed.

As nasty as they are NATs are unfortunately, a way of life. By the way, 
I like the work you and others have done on teredo to punch holes in 
NAT.

> normal IPv4 addresses do not become invalid at a whim (absent device

Neither do IPv4 link-local addresses. Read the draft. In most cases 
conflicts will be detected before an address is assigned to a machine. 
The only place it is even remotely likely that two machines will have 
the same address is the case where you bridge to previously separate 
networks together that have machines with IPv4 link local addresses 
assigned. I suppose the way in which IPv4 link-local addresses are 
significantly different from normal IPv4 addresses is that the 
conflicts will be detected right away instead of leading to mysterious 
problems that are hard to diagnose.

As pointed out by others, using DHCP can lead to addresses changing. 
Just like with IPv4 link-local addresses, these address changes are 
rare, assuming the DHCP server is configured correctly.

Another very common situation for addresses changing is a person moving 
their computer. I've got a laptop, I take it between work and home 
every day. Every day I switch my IP address when I get to work and 
again when I get home. Most applications on my computer are aware of 
the address changes and work without any difficulty. In addition, many 
people use dial-up connections where the connection may drop often. It 
is very handy for applications to be aware of the state of any 
connections to the network and act accordingly. It is naive for an 
application to assume that it has statically assigned addresses that 
never change.

> addresses suddenly stop working due to conflicts.

Normal IPv4 addresses, as noted above, will fail in a more mysterious 
manner when conflicts occur. IPv4LL addresses will be reassigned and 
networking operations can continue without intervention. I haven't yet 
heard of an example of a case where using a private address and NAT for 
referrals to other devices would succeed where an IPv4LL referral would 
fail.

I haven't read much of the IPv6 RFCs. Do they suggest application 
developers treat IPv6LL addresses different from global scoped IPv6 
addresses?

> but you knew this already.

We do know that this is what you've been saying. Please give us some 
examples of where this could cause problems.

-josh

---

From: Keith Moore <[email-masked]>
Date: Mon, 02 Sep 2002 10:02:58 -0400

> software doesn't work with a NAT, your software can not be widely 

actually, that's not even true.  what it means is that your software
cannot work behind a NAT.  this certainly limits the environments
in which the software can be run - e.g. the software will not automagically 
work from anywhere in what users think of as "the net".  but the existence
of NATs does not prevent software that doesn't (and fundamentally cannot) 
work with NATs from existing and being useful.

OTOH, linklocal - because it ships with the OS, gets enabled by default,
and is there all the time, imposes NAT-like restrictions on networks 
that haven't chosen to run NAT.   and it imposes new burdens on existing
applications that were working just fine on their networks - now those 
apps either have to explicitly refuse to use LL addresses or they have to 
explicitly specify interfaces and try to recover from broken connections.
even then they'll fail more often with LL addresses than before.

> As nasty as they are NATs are unfortunately, a way of life. 

they're "a" way of life.  not "the" way of life.  if you're trying to
sell an app to the mass market, you probably assume that either your
app works with NATs or you can't succeed.  but that doesn't mean
that all networks work this way, or that no app can be useful unless it's 
NAT-compatible.

> Neither do IPv4 link-local addresses. Read the draft. 

as you're probably aware, I have read the draft on multiple occasions
and have made extensive comments about it.  so when I say "invalid at a 
whim" you should interpret that as coming from someone who has repeatedly 
read the draft and who understands the conditions under which LLs become 
invalid.  IMHO such failures are not negligible.

the additional faliures introduced by LLs might be acceptable if you
design your network with such failures in mind (to limit the number
of devices on a logical link) - but existing networks were not
designed with linklocals in mind.  for instance it's fairly common 
these days to use moderately sized subnets and L2 switching.
in those cases LL collisions can be expected to be more common.

> In most cases 
> assigned. 

or when you have machines with interfaces on multiple networks 
(increasingly common)  or when network congestion (not unusual)
prevents the claim/defend protocol from working.

I suppose the way in which IPv4 link-local addresses are 
> problems that are hard to diagnose.

normal IP addresses do not have such conflicts. when such conflicts
do arise, it is due to improper configuration, and hosts and apps
aren't expected to deal with those problems.  however the LL
draft makes clear that hosts and apps are expected to deal with
problems caused by LL - even though there's no way of either avoiding
such failures (since LL is imposed on hosts) or transparently
recovering from such failures.
 
> rare, assuming the DHCP server is configured correctly.

again, the fact that DHCP can cause problems if misconfigured is not
an argument for LL causing problems.

> application to assume that it has statically assigned addresses that 

no, it's not "naive" of an application to assume that - in fact, many 
applications quite reasonably *do* assume that (for instance, the vast 
majority of servers on the network).  yes, it's an operational constraint, 
but it's not a rare one.

rather, it is naive of LL proponents to assume that all applications work
like the ones on their laptops and can operate under the same set of
constraints that are imposed by nomadic hosts.

> manner when conflicts occur. 

again, the potential for other sources of failure is not a justification 
for LL imposing failures.  

> IPv4LL addresses will be reassigned and 
> networking operations can continue without intervention. 

no they will not.  existing connections/associations will break, existing 
apps using those connections/associations will fail, and in general there
is no way for those apps to recover.  in the vast majority of cases
intervention is necessary to restart the operation, restart the app, 
etc.  and it's not reasonable to assume that such apps are interacting
with a human user who is monitoring the situation and can quickly initiate 
recovery.

> I haven't yet 

it can happen anytime the network behind the NAT is subnetted.

but you seem to be arguing that the existence of NATs is license for
LL to cause many of the same problems that NAT cause.

> developers treat IPv6LL addresses different from global scoped IPv6 

yes, they are treated differently.  there's an address selection algorithm
that tries to specify when to use certain kinds of addresses.  it doesn't
entirely solve the problem.  but at least the IPv6 people admit that the 
problem exists.

> examples of where this could cause problems.

I've given examples on numerous occasions.  the problem seems to be
that folks here think it's perfectly reasonable to force the entire 
network to operate under the constraints of a nomadic laptop that
only connects from behind NATs.   most people only see their email 
client, IM client, and web browser, and they think that is representative 
of the entire network.  in reality the network is far more diverse
than that.

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 3 Sep 2002 14:53:40 -0700

> work with NATs from existing and being useful.

Your assertion was that the zeroconf working group is trying to 
"redefine IP to work differently than applications expect". Your 

> without the application having to worry about which network

As pointed out before, this is not true. RFC1918 specifies private 
address ranges that are not in any way globally unique.

> even then they'll fail more often with LL addresses than before.

As far as I can tell, there is no requirement in the current draft that 
a host must acquire an IPv4LL address in addition to a globally scoped 
address. For the very reason you state, I think it makes more sense for 
hosts to only acquire IPv4LL addresses when a configured address is not 
available. I believe it makes sense to retain any IPv4LL address 
acquired even after a globally configured address becomes available to 
maintain any TCP sessions already using the LL address. In that case, 
the IPv4LL address may present similar problems to NAT.

> that all networks work this way, or that no app can be useful unless 

This is true, but those applications ignoring NAT are making certain 
assumptions that, while possibly true for a specific 
configuration/situation, are not true for the IP in general.

> in those cases LL collisions can be expected to be more common.

The number of devices on a logical link must be limited for other 
reasons. In addition, the collision detection used before an address is 
picked should eliminate the possibility of two nodes self assigning the 
same address. If the logical link is so large that there is a 
significant amount of packet loss so that the collision detection is 
failing, then the network is poorly designed and the collisions are 
just one symptom.

Using a real world example (which I believe has been used before). An 
AppleTalk network, which uses a similar mechanism to allocate 
addresses, and has nearly as many nodes as addresses available does 
work without the addresses changing constantly. It did take a long time 
to find an unused addresses, but once an address was acquired, it 
worked and there were rarely collisions. This is a pathological case 
where the number of nodes where very close to the number of addresses 
available. Do you think that logical links with more than 32k nodes are 
common?

You said "IMHO such failures are not negligible.". Do you have any 
evidence, models, something to back that up? Using AppleTalk's address 
allocation as an example to study, such failures are negligible.

> prevents the claim/defend protocol from working.

If congestion is causing the claim/defend protocol from working, the 
network is probably running in to other sorts of problems as well. 
IPv4LL address collisions would just be one symptom of a poorly 
designed network.

I had not considered how a machine with multiple interfaces on 
different networks could cause problems with address collisions. The 
draft does suggest that a multihomed host should try and keep it's 
addresses unique on all interfaces. If a device with multiple 
interfaces already has 2 unique IPv4LL addresses on two different 
networks and a third interface is plugged in to a third network network 
that already has one or two of the devices addresses in use, what is 
the multihomed device supposed to do? It seems to me it would need to 
allocate new IPv4 link-local addresses that are unique across all three 
interfaces.

> recovering from such failures.

Normal IP addresses do have such conflicts and they are due to improper 
configuration. Hosts and apps should not be expected to deal with such 
problems. It would be nice if stacks did a better job of detecting this.

> an argument for LL causing problems.

This is not an argument that it's alright for LL to cause problems but 
just an observation that most applications already live in a dynamic 
environment were addresses and connectivity do change. Again, I think 
you overestimate how often IPv4LL addresses will change.

Just as DHCP misconfiguration can cause problems, a poorly designed 
network with a enough congestion that the IPv4LL claim/defend mechanism 
fails can cause problems.

> constraints that are imposed by nomadic hosts.

In the statically configured world where an application can assume it's 
address, and the addresses of other nodes will not change, the 
applications will most likely be configured to use those static 
addresses. This sounds like a highly configured environment, it is not 
clear why IPv4LL addresses would be use instead of the configured ones.

> with a human user who is monitoring the situation and can quickly 

Not true, if service discovery is used or name to address mapping, when 
communication does break, an application could easily find the new 
address and resume communication. This certainly would require 
modification of an application.

You still haven't presented any evidence that IPv4LL addresses are 
likely to change often as you suggest would happen.

> LL to cause many of the same problems that NAT cause.

Networks can break in many ways when you start using private addresses 
on separate networks. Does that mean we shouldn't do that? Since IPv4LL 
addresses may cause some problems in some edge cases, does that mean 
that they are useless? I don't think so.

You still haven't backed up your assertion that the zeroconf working 
group is trying to "redefine IP to work differently than applications 
expect". So far, your arguments seem to point to some applications that 
expect a configured environment with addresses that will never change 
and all addresses that are globally accessible. I don't think it's 
right to assume that IP applications expect that or even require that. 
RFC1918 specifies addresses that are not global in scope, so an 
application can not expect every IP address to have global scope. 
Applications assuming global scope are making assumptions beyond those 
that IP defines. NATs make it easy to send data from private addresses 
to the global internet, making it trivial to leak private addresses. 
These are not excuses for making something else that causes problems. 
They are examples of other things that, while they have the potential 
to cause problems, are in general, very useful and widely deployed.

> entirely solve the problem.  but at least the IPv6 people admit that 

Source address selection is covered in section 2.6 of the ipv4 
linklocal draft. Selection of remote addresses from name lookup, 
service discovery, or other sources has not been addressed.

-josh