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

From: Erik Nordmark <[email-masked]>
Date: Sat, 4 Jan 2003 09:04:28 +0100 (CET)

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

John, 

Your comparison with client and servers in different subnets without a router
makes me think the problem case hasn't been well explained.

Let me try to explain an IP address configuration example where Keith's issue
might appear and that is unique to different address scopes i.e. not
related to a general inability to communicate.

Imagine three boxes on a local link: A, B, and C.

C is a link-local only box. It has the link-local address C(LL).

A and B are full function boxes (support both DHCP and V4LL).
They acquire their link-local addresses (e.g. because the dhcp server is
not up when they boot, or because they need to them in order to communicate
with C). Thus A has A(LL) and A(G) assigned to the same interface. Similarely
for B.

The issue appears when a node outside the link (call it D) communicates
with A and B and there is a referral going on.
If A wants to refer D to B, it must pass B(G) to D since D can not reach B(LL).
How can this be ensured unless the application is link-local aware?

When looking for specific applications that might fail in such a case
I think one needs to understand how the application instances discover 
eachother. If this discovery process uses agents outside of the link
then the process would presumably only discover the global addresses of
its peers, even if those peers are on the same link and have a link-local
address. But are there applications that use other discovery mechanisms and
referals that would run into trouble in the above example configuration?

Thus the issue isn't about link-local addresses. The issue is how boxes
(and the applications running on those boxes) handle the case when the
box is configured with addresses of multiple scopes.

  Erik

---

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

> with C). Thus A has A(LL) and A(G) assigned to the same interface. Similarely

Right...so now A is using single link multihoming, just like any one of
thousands of web servers around the world. Nothing new there.

> How can this be ensured unless the application is link-local aware?

But this same situation can come up, and *does* come up with firewalls and
NAT. So , (and this is my point), while this can be problematic, this is
neither new, or unique to v4LL, so we aren't treading new ground here. As
well, it might not be a bad idea to include specific text to point out to
implementers that this situation might happen, and that they need to handle
it gracefully so that non v4LL - aware apps can be used more properly.

> referals that would run into trouble in the above example configuration?

Maybe...how much time to we have to check the operation of every IPv4 -
aware app ;-)

> box is configured with addresses of multiple scopes.

Right...but again, this isn't new ground, nor v4LL - Unique. For some time
at a previous company, I had to have my laptop configured with a NAT and a
global address at the same time. I found that my major problems dealt with
the OS software getting confused occaisionally, but that as long as the OS
was not getting cranky, the apps were fine. This is *obviously* a single
case, but I think that as long as the IP stack is dealing with this
correctly, the apps should be fine. After all, that's why we have layers, so
the apps don't need to care.

john

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 8 Jan 2003 10:11:52 -0500

> neither new, or unique to v4LL, so we aren't treading new ground here.

So you are admitting that v4LL does not meet the IETF criteria for 
proposed standard, which say nothing about "not treading new ground"
but do say "no known technical omissions".

Or are you trying to use other people's mistakes - which were never 
standardized - as a justification for zeroconf making even more 
mistakes and insisting that IETF standadize those mistakes?

> correctly, the apps should be fine. 

You're simply wrong about that.  Somehow I don't think the Internet should
have to be penalized because of the ignorance of people who think that "apps
should be fine"  with whatever ill-conceived havoc they wish to impose - 
particularly when those people deliberately chose to ignore evidence to 
the contrary.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 08 Jan 2003 07:37:16 -0800

> mistakes and insisting that IETF standadize those mistakes?

Keith, you and I had a month long running battle on this off list. I think
NAT, like any other tool has it's place, you evidently wish for severe
corporal punishment for anyone not spitting at the sound of its name.

So be it, we simply disagree here.

However, my point was, that this problem exists *now*, is handled *now*, so
is not some 'new, unseen issue'. This means that there are ways to deal with
it in an intelligent, calm, rational manner.

> particularly when those people deliberately chose to ignore evidence to

Well, your Internet is evidently a far more fragile place than mine. If the
Internet can handle the silliness that it handles now, I fail to see how
v4LL will collapse it. Didn't Bob Metcalfe have to literally eat his words
over his predictions of imminent Internet collapse? It's fun to predict, it
isn't going to happen anytime soon, and if it does, it won't be due to v4LL.

As well, if you wish to offer hard, happening evidence, that can be
reproduced by all, well documented, etc., I welcome it. That is how things
get fixed. A problem is discovered, defined, and fixed. I fix things, it's
what I do. I will spend whatever time it takes to fix a problem, but I have
no time to waste on bemoaning it's existance.

john

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

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 8 Jan 2003 16:48:45 -0000

> From: "John C. Welch" <[email-masked]>
>

A difference is that I generally know when I am operating on a network
hiding behind a NAT or Firewall gateway and it doesn't require a very high
degree of knowledge to understand how distributed operations may not work
properly through the gateway - the very term "gateway" implies it.

If I put my equipment directly on the internet - something which doesn't
actually require very much management and expertise these days, then I will
be upset if applications still fail for the much less obvious reason that
they are using the "wrong" IP address in referrals.

In the example given, both boxes A & B work OK in simple exchanges with
hosts on other networks and also with each other without me even knowing
that they have LL addresses - both are "LL aware". However, when an three
point operation involving referrals is used the failure could well be
intermittent and hard to troubleshoot.

Are there other examples of scoped addresses of this nature where there
isn't a single obvious restricted point of contact between networks (the NAT
gateway)? You could cite the use of other unroutable networks (10.x.x.x etc)
but are these commonly run concurrently with global addresses on multihomed
hosts? If so how are the problems solved?

Philip Nye

---

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

> but do say "no known technical omissions".

No, Keith, I don't think he's beaten his wife lately.

---

From: Alf Watt <[email-masked]>
Date: Wed, 08 Jan 2003 12:41:18 -0800

When communicating an address to a far away host applications SHOULD check
to make sure it's a public address before sending. That's just good
defensive programming, the private address blocks are well-known and can
easily be checked for. When receiving an address from a far away host the
same check MAY be performed for sanity.

Second, due to the dynamic nature of both DHCP and LL self-assigned
addresses, applications SHOULD perform late binding of network names to
addresses and not exchange addresses at all. When sending address
information to a far away hosts only unicast-dns names should be used.

See section 2.8 of "Replacement of AppleTalk NBP":

http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt

Best,
Alf

On 1/8/03 6:59 AM, "John C. Welch" <[email-masked]> wrote:

> was not getting cranky, the apps were fine.

---

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

> hosts? If so how are the problems solved?

Yes, at least in my experience, you do run into these things, for certain
types of servers that have to live on the threshold.

The problems are solved based on OS implementation and limitations. For the
Macs, we just added a second router address, but this was a manually
configured environment. The Windows boxes at the time were more limited, so
they required someone with a Mac or a Sun box to be an intermediary. (our
windows users at the time didn't hit this wall much, so it was not a great
problem.) I wasn't running the Sun boxes, so I wasn't involved with
configuring them, but it was probably the same thing as the Macs, or not
much harder, since the total fix time was about an hour.

john

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