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

From: "Martin Layley" <[email-masked]>
Date: Wed, 8 Jan 2003 16:35:33 -0000

Most UK subscribers to dial-up or broadband (ADSL or cable) have no choice.  NAT is the default.  Non-NAT connections are far & few between (and expensive).  The very environment where zeroconf is going to be most useful - plug & play - is the environment where NAT is most likely to be in place.  Having looked at Keith's software, I see no reason why it should not work within the confines of an unrouted network, whether formed from automatically or manually assigned addresses.  If it needs to work over a wider area, such as via an ISP, then this will obviously involve a router.  The problem then becomes one for the zerorouter group and not zeroconf.

		Martin

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: 08 January 2003 16:11
To: John C. Welch
Cc: [email-masked]; [email-masked]
Subject: Re: Application software needs to be "zeroconf-aware"?

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

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

NAT is of course a useful tool if you respect its limitations.  But it
has such severe limitations that it's not suitable for IETF
standardization.

> However, my point was, that this problem exists *now*, is handled 
> *now*, so is not some 'new, unseen issue'.

and you are simply wrong.  or at the very least, it is a gross
over-generalization to say that because NATs exist and are widely
deployed in some environments, that it's acceptable under IETF
standardization criteria to impose NAT-like problems on *all* IP
networks.  for instance, networks that use NATs tend to be heavily
client-oriented, because the workarounds necessary to support
significant numbers of servers/listeners behind a NAT are infeasible.

> This means that there are ways to deal with
> it in an intelligent, calm, rational manner.

I don't see how being intelligent and rational is consistent with
ignoring the criteria in 2026 or with ignoring evidence that v4LL
causes problems.

> If the  Internet can handle the silliness that it handles now, I fail
> to see how v4LL will collapse it. 

whether the Internet will collapse is not the question at hand.
the question is whether v4LL meets the criteria in 2026, which 
set a much higher bar than "whether the Internet will collapse".

> As well, if you wish to offer hard, happening evidence, that can be
> reproduced by all, well documented, etc., I welcome it. 

download netsolve and install it, and try to run it with some mixture
of clients, servers, and agents, inside and outside of a NAT.
see http://icl.cs.utk.edu/netsolve/

--
Keith Moore                              http://www.cs.utk.edu/~moore/
27 February 1933                                     11 September 2001

The mail message has been scanned by MAILsweeper
for content analysis.

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 9 Jan 2003 09:38:17 -0000

> From: "Colin Perkins" <[email-masked]>
>
> >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?
>
> Scoped IPv4 multicast addresses have the same issues, and cause the same
> sorts of problems when trying to invite a client to join a multicast
> session.

This is interesting as I am developing applications which will make heavy
use of multicast.

In this instance the multicast scope is very much manually configured and
generally the scoping will be managed to take account of the applications
being run. Also, is it not the case that the application (or at least the
multicast address allocation mechanism) will nearly always be scope aware?

The thing about zeroconf is that as proposed, it will be deployed by default
without users really being aware of it and as the referral example has
shown, the fact that the stack is LL-aware will not prevent breakage. There
is a demonstrated failure mode here which so far as I can see is unique to
LL or at least severely aggravated by it. Users may be in a position where
either there application will not work (LL turned on) or they will not be
able to talk to their printer (LL turned off) - and making the choice is a
manual configuration option!

As Brad Hards' message said, this is not to say that the benefits do not
outweigh the disadvantages - I do not have much sense of the scale of the
problem in terms of the prevalence of the sort of application which will
break and the chances of these applications being updated.

Philip Nye