Subject: Application software needs to be "zeroconf-aware"?

From: Stuart Cheshire <[email-masked]>
Date: Fri, 27 Dec 2002 16:14:09 -0800

>Having compatibility with non-zeroconf-aware hosts is of little value if 
>the applications on those hosts aren't zeroconf aware.  And the set of 
>applications that can run transparently with link local addresses is 
>relatively small.

Keith, I know you just bought yourself a Titanium PowerBook G4.

Mac OS X 10.2 comes with a bunch of network software (ftp, ssh, 
AppleShare, LPR/IPP printing, Web browser, iChat, etc.)

If you connect your Mac directly to another Mac (or a Windows machine) 
with an Ethernet cable, and let them both acquire IPv4 link-local 
addresses, then can you tell me what network software *doesn't* work?

Can the AppleShare client connect to an AppleShare server on the other 
machine? Can an ftp client connect to an ftp server on the other machine? 
Can a web browser fetch pages from a web server running on the other 
machine?

Don't bother telling us that you tried to buy a book from Amazon and it 
didn't work, or that you tried to send email to someone in another 
country and it didn't work. We know the worldwide Internet is really 
useful. No one working on Zeroconf has argued that it isn't. The point of 
Zeroconf is not that we don't need a worldwide Internet. The point of 
Zeroconf is that it would be useful to be able to use that same IP 
software when you're not connected to the Internet. You can use a web 
browser for on-line shopping. It is beneficial to be able to use that 
same familiar web browser software also to check the status page of your 
directly-attached printer when you want to check its ink levels.

None of the applications on your Mac have been modified to be specially 
aware of IPv4 link-local addresses, yet they all seem to function well 
enough for people to get useful work done. How many of those unmodified 
applications work today using IPv6 link-local addresses?

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Dec 2002 20:10:23 -0500

> addresses, then can you tell me what network software *doesn't* work?

your question constrains the answer in a way that would make the answer 
misleading.  most apps that would work on an isolated network with
only two hosts and statically-assigned IP address literals would work 
as well with v4LLs.  so if the only apps you care about are those that 
only need to work between two hosts on an isolated network, LL is great
for you.  but many other apps will fail in the presence of v4LL.  
pretending that those apps don't exist, or are not important, isn't helpful.

> The point of 
> software when you're not connected to the Internet. 

then please fix v4LL so that it's disabled whenever you are connected to
a larger network.  that way it won't break anything that already works.

Keith

---

From: Alex Karahalios <[email-masked]>
Date: Fri, 27 Dec 2002 18:27:02 -0700

Hi Keith,

Could you give us some examples of what specific apps would fail and 
how they would fail?

Thanks,

Alex Karahalios

On Friday, December 27, 2002, at 06:10  PM, Keith Moore wrote:

>   but many other apps will fail in the presence of v4LL. 
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Dec 2002 21:23:04 -0500

> Could you give us some examples of what specific apps would fail and

I've done this many times.  

distributed apps will fail; examples include gnutella (and friends), apps 
based on globus, pvm, netsolve; apps that use sip.  also some distributed 
games, some conferencing software, but since I don't use these I can't name 
specific instances of these.

apps that expect to be able to associate DNS names with hosts will also 
fail since LL addresses should not be advertised in DNS.  or if they
are advertised in DNS, they will fail if the scope of the app is beyond
the local link.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 27 Dec 2002 23:30:06 -0500

> pretending that those apps don't exist, or are not important, isn't helpful.

Keith, either find us a bug, or stop saying the sky is falling. One would be
highly productive, the other is a waste of time.

> a larger network.  that way it won't break anything that already works.

Nonsense, that's absolutely the wrong way to go. I have two interfaces, and
each can have its own IP address, and in fact, can easily handle multiple IP
addresses on each interface. Therefore, there's no good reason whatsoever to
not allow me to communicate on different networks simultaneously, and if one
of those is LL, so what?

john

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

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 27 Dec 2002 23:36:55 -0500

On 12/27/2002 21:23, "Keith Moore" <[email-masked]> wrote:

> distributed apps will fail; examples include gnutella (and friends),

That's pretty interesting since I use Limewire and Rendezvous all the time.

> apps 
> based on globus, pvm, netsolve; apps that use sip.

Really? They would break because they can't get to the public internet, or
the mere presence of LL disables them? One makes sense for reasons that have
nothing to do with LL, the other shows that they are obviously too fragile
to function.

> also some distributed

Well, I *can* say that Unrealy GOTY, Baldur's Gate II, and SquidCam work
jes' peachy in the presence of LL. Maybe you should use some apps here.

> are advertised in DNS, they will fail if the scope of the app is beyond

This is:

A)  Misleading. First of all, why would you have a Unicast DNS server
running on a LL network? Secondly, an app using DNS names without DNS
services is going to fail ANYWAY, there's NO DNS. LL is NOT DNS, and has
nothing to do with DNS, please stop trying to confuse the issue.

B)  If you take mDNS into account, you're wrong anyway.

C)  If the app is trying to connect to something that can't be reached of
COURSE it's going to fail, this is true on a manually configured network
with Unicast DNS. Lemme yank the connection to the public internet, and
watch things break.

Again, do you have anything that is an LL issue, not a common sense issue?

john

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

---

From: Ian Lister <[email-masked]>
Date: Sun, 29 Dec 2002 00:07:11 +1000 (EST)

>That's pretty interesting since I use Limewire and Rendezvous all the time.

Rendezvous/zeroconf as implemented in Mac OS X 10.2 doesn't assign an
IPv4LL address to an interface when it has already obtained an address for
that interface. I believe this difference between the draft and the
existing implementations is one of Keith's primary concerns.

Ian

P.S. note that OS X 10.2 does create a IPv4LL route, which ensure a host
with a configured address can still communicate with a LL-only host on the
same link.

---

From: Ian Lister <[email-masked]>
Date: Sun, 29 Dec 2002 00:11:55 +1000 (EST)

>specific instances of these.

Perhaps it would be helpful if you picked two or three of the above
examples and spelled out exactly how these applications will fail, in
enough detail that nobody will be in any further doubt?

Ian

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Dec 2002 09:45:44 -0500

> enough detail that nobody will be in any further doubt?

I've already explained this also.  Apps will fail when they try to use
limited-scope addresses from outside of their scope, either by trying to
contact those addresses or by trying to use them as unique identifiers. 
Such addresses can be obtained either by referral (transmitting the IP
address) within the application, or referral via another application 
(including but not limited to DNS).

---

From: Ian Lister <[email-masked]>
Date: Sun, 29 Dec 2002 01:24:14 +1000 (EST)

>pretending that those apps don't exist, or are not important, isn't helpful.

I think your point here is that zeroconf on disconnected networks is all
well and good (enabling various applications to work where they otherwise
couldn't), but introducing it on connected networks that already have
wider scope addressing schemes in place might cause existing applications
to fail, due to attempting to use link-local addresses to communicate
between links. Is that correct?

>contact those addresses or by trying to use them as unique identifiers.

You're really going to need to be specific about this in order to convince
anybody. Pick an application, tell us how it works, and show how IPv4LL
prevents it from working.

>address) within the application,

A classic application that does this is FTP (one that has, I might add,
been broken by other extensions to usage of IP such as NAT, but where
people preferred to use the extensions and work around the protocol rather
than prevent use of the extension).

FTP is *not* broken because implementations use getsockname() or
equivalent to find an appropriate local address to transmit. It would seem
that any other application transmitting addresses directly should be doing
the same, too. (Picking an arbitrary local address would be broken anyway,
because a host could have addresses on different networks that cannot be
routed between.)

Can you name any applications that use direct referral of addresses and
*are* broken by IPv4LL?

>                                 or referral via another application

What in the zeroconf drafts will lead to IPv4LL addresses going into DNS?
They may be advertised by mDNS but by definition that's LL only anyway.
If anybody for some reason starts putting them (or allowing them to be
put) into a unicast DNS zone then that's an administrative issue to ensure
they are not published beyond the link, rather than a legacy fragile
software issue, isn't it? It's just the same as with scoped IPv6
addresses, and administrators have just as much control over how and
whether they should be published in DNS.

Can you name any applications that use indirect referral of addresses and
*are* broken by IPv4LL?

Assuming you can provide some examples and convince the members of the
group to see this as a problem, I see several options that you might think
appropriate paths forward:

1. Require that IPv4LL be active only on hosts that are unable to find an
   address any other way.

2. Require that existing system APIs for enumerating system addresses not
   return IPv4LL addresses if others are available, and that (in that
   case) IPv4LL addresses must be explicitly asked for.

Would either of these options satisfy you? Do you see any other options?

>a larger network.  that way it won't break anything that already works.

If the draft were changed to do this (i.e. option 1 above, so that it
matched the behaviour of existing implementations) would you be happy with
it?

Ian

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Dec 2002 11:19:06 -0500

> between links. Is that correct?

Yes.   (though there are other reasons that v4LL can cause problems than
attempts by apps to use v4LL addresses from outside of their scope)

> Pick an application, tell us how it works, and show how IPv4LL

I've already done this, multiple times.

> been broken by other extensions to usage of IP such as NAT, 

Note that NAT has never been standardized for the very reason that it breaks
so many apps - but that hasn't stopped zeroconf from demanding that v4LL 
be standardized when it breaks a similar number of apps, for similar reasons.  

> but where

FTP does this.  HTTP can also use IP addresses in referrals and there are 
good reasons to use IP addresses in local referrals (where the referring server
reliably knows the IP address of the server being referred to) as it improves 
reliability and performance.  SIP can use IP addresses in referrals also, and this 
speeds call completion and is more reliable than requiring DNS lookups.  Gnutella 
passes IP addresses over the network, both to identify resource locations (you can find 
resource X at address Y) and to identify nodes that can perform routing of traffic.    
It does have ways of trying to work around NATs and firewalls, and these might 
(with some modification) also work for hosts using LL.  But this degrades 
functionality and performance for those nodes.  (And they don't work entirely - 
if you look at traffic you'll see referrals for resources at RFC 1918 addresses.   
They can be filtered but the basic problem is that a node has no way of knowing 
whether a 1918 address - or for that matter a v4LL address - is in its scope 
or not.)

The applications that I'm most familiar with that have problems with scoped
addresses are distributed apps used in high-performance computing.

For instance, PVM (parallel virtual machine) maintains a list of (host #, 
IP address) pairs for every host that is used in the computation; this list 
is replicated on every host within that computation. PVM expects to be 
able to send traffic from any host to any other host in the machine.
Naturally this will fail if some of those IP addresses are LL addresses and
some of the hosts are not in the same scope.

MPI implementations that work over IP do much the same thing.

(Both PVM and MPI support a model where computational nodes are represented
by small, dense integers - e.g. from 1 to N.  Many distributed computations 
are written to use this kind of model - it makes it easy to divide a problem
up into N portions, for instance, and it also makes it easy to store 
per-node information in arrays.)

NetSolve has processses known as agents which keep lists of (problem, IP address, port) 
triples, which describe that a particular server host listening on a particular port is 
willing to perform a particular kind of computation for a client.  A NetSolve client that 
wants that kind of computation will query a NetSolve agent for the address of a host that 
is willing to perform that kind of computation.      The client will then contact the 
server host directly.   Obviously this will fail if the IP address of the server is a
v4LL address and the client and server (or agent and server) are not in the same scope.

> Would either of these options satisfy you? Do you see any other options?

I've suggested both of these in the past.    I've also suggested that there
be a standard way for managed networks to be able to disable v4LL, in order
to work around this and other problems that v4LL might cause.

> matched the behaviour of existing implementations) would you be happy with

This is most of what I've been asking for for several months.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 28 Dec 2002 12:32:25 -0500

> contact those addresses or by trying to use them as unique identifiers.

But that would apply to *any* situation with limited scope addresses. A
network NOT connected to the public internet would have the *same* problem
under the same circumstances. This has *nothing* to do with LL, and
everything to do with the saying, <Maine geezer accent>"You cahn't get thea
from hea"</Maine geezer accent>. If I put a cleaver through all of your
connections to the external world, even IPv6 is going to lose it's little
mind.

> (including but not limited to DNS).

Again, you're talking about situations in which any addressing method is
going to fail, and this includes even your much - vaunted IPv6.

john

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

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 28 Dec 2002 12:59:23 -0500

> attempts by apps to use v4LL addresses from outside of their scope)

And that can be handled by any number of methods before applications see it,
enough that it would be silly to enumerate them all in the spec. It's a
spec, not a howto. And any addressing method used outside of it's scope is
going to fail.

> I've already done this, multiple times.

You have yet to name a single application. You name general types, you name
theories, but not a specific application that *anyone* can observe failing
and be able to identify the problem, and then the solution. One might think
you don't actually *want* a solution, just an unending list of problems to
torpedo zeroconf entirely.

> be standardized when it breaks a similar number of apps, for similar reasons.

One example Keith. One specific application that can be downloaded and
tested. And NAT works correctly when implemented correctly, but that's a
different horse to beat.

> functionality and performance for those nodes.  (And they don't work entirely

Um, Gnutella handles NATs just fine...wait, let me look...yep, running just
fine through a NAT, and all it's features work right too. Hmmm.

As well, you *can* do a lot of things. Using hard-wired IP addresses instead
of DNS names is just dumb, *unless* you have no other choice. Considering
the ubiquity of DNS, I'm thinking that will happen not often at all. As
well, if DNS is so unreliable, then why use it at all? Oh wait, it isn't
unreliable, but it *can* be slower.

> - 

No, you don't until you try to use it. That's life on the internet. The Web
server you were using just a second ago crashed, oops, that address is no
longer valid, so sad, too bad. You can't prevent that.

> some of the hosts are not in the same scope.

Well, you'd have to be pretty careless to set up a PVM, and not double check
that all your machines are on the same subnet. That's going to bite you LL
or not. If all the machines can use LL addresses, and they are all on the
same physical net, then they can see each other. It's only if some are *not*
able to use LL at all then you would have problems. Of course, this is
easily fixable, unless the LL machines could ONLY use LL, and I have yet to
see anyone dumb enough to put out a stack that can't be at least manually
configured. 

Your example fails under manual addressing errors to.

> v4LL address and the client and server (or agent and server) are not in the

This will also fail if the IP address of the client and server are in
completely different subnets without a router. Again, yes, that is a failure
condition, but it is hardly unique to LL, and is only going to be a *hard*
failure if the LL machine cannot be configured to use a non-LL address.
Considering every IP stack since IP began can be manually configured, I'm
not real worried about anyone with two functional brain cells eliminating
this ability.

> to work around this and other problems that v4LL might cause.

You have yet to enumerate a single v4LL problem that isn't a problem for
*any* v4 implementation, LL or not. Okay, let's restate this...name a
problem that is *created by*, and *unique to* v4LL.

As well, requiring either of those two options is going to break the idea of
zeroconf. If I'm at a seminar, and I just need to print, and I have manually
configured IPs on all my interfaces, and there is a nice zeroconf wireless
network for printing, then the *only* way I can use that network is to
*manually* enable zeroconf on that interface, and then later having to
*manually* disable it on that interface so I can use my manual settings.
(remember boys and girls, manual configs don't have any external methods to
tell you that you're configured.)

The idea with Zeroconf is that you don't.have.to.manually.do.anything.
It.just.works. No manual configuration occaisionally. None. Yes it means
that the vendors have to do more work for this, but not a lot of work, since
single - link multihoming is in use every day by thousands of machines, and
works real well. Multiple IP's on a single interface is not new. Neither is
multiple IP's on multiple interfaces. It's been being used, without problems
for *years* in the real world.

Zeroconf's only purpose is to make IP networking easy. Not easier. DHCP did
that. Easy. And easy for non-technical types. They way AppleTalk did over
ten years ago.

Why is that so alien? This isn't for us. We don't need it. It's for them. Ma
and Pa Kettle. Salesmen at a client's. Kids in a dorm. Teenagers who just
want to play a nice round of Unreal without needing to reconfigure IP
stacks.

If we cannot agree that ease of use is the primary, and indeed only reason
for this standard to exist, then I vote we kill the entire IETF effort on
zeroconf, indeed, *any* IETF effort that tries to mention ease of use, stop
wasting time, and let the vendors sort it out.

john

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