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

From: Keith Moore <[email-masked]>
Date: Wed, 08 Jan 2003 19:15:24 -0500

> Having looked at Keith's software, 

Clarification: NetSolve is not my software.  I just happen to work in
the same group as the folks who maintain it, and occasionally they ask
me to help them with thorny problems like "How do we make this work
across a NAT?"

> I see no reason why it should not work within the confines of an
> unrouted network, whether formed from automatically or manually
> assigned addresses.  

NetSolve works fine on an isolated network, and is often demonstrated
that way.

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

This is where I strongly disagree.  The problem is that (the charter
notwithstanding) zeroconf's link-local proposal will affect all
networks, not just isolated networks, and the cases where link-local
causes problems are on networks that have external connectivity.  It's
not acceptable for zeroconf to break operation of applications on
connected networks, and it's not acceptable for zeroconf to break
things and claim that they're somebody else's problem to fix.

Keith

---

From: Brad Hards <[email-masked]>
Date: Thu, 9 Jan 2003 19:45:15 +1100

> things and claim that they're somebody else's problem to fix.
I think this is where we differ.

_Anything_ that the zeroconf group can do can almost certainly be shown to 
modify the behaviour of at least one application. Some combination of 
protocol design (or protocol design error) and program design (or program 
design error) will ensure that this is the case.

I don't care if that happens. I _DO_ care if major applications break. If 
specialist applications break, then don't run them and zeroconf at the same 
time. Zeroconf is a technology that can be run in major data centres, but the 
people with the specialist applications are the ones best able to handle the 
breakage and modify the configuration of the hosts/networks to compensate.

I don't want gratuitous breakage. If there is going to be problems, then I'd 
like to know. After all, that is why I keep updating zcip to track the I-D - 
so that we can make an informed decision, including abandoning the current 
approach and working on an alternative (which might still cause breakage, but 
at an acceptable level). However the progression of zeroconf should be judged 
on the balance of the advantages and disadvantages, not just the absence of 
disadvantages.

The social equity aspects of zeroconf are probably worth mentioning here: at 
the moment, ability to use the internet (or local network) is basically the 
domain of the technical elite. If we pass up the opportunity to make this 
type of technology more accessable, just so someone's computing cluster 
doesn't need to be modified, then that would be sad. It might even be 
unethical.

We generally agree that transitioning to IPv6 is going to be painful. A lot of 
applications needed to be updated, and it has, does, and will continue to 
cause breakage. But we also agree that it is going to be worth it in the end. 
Zeroconf should be considered in the same way.

Summary: if one (or a few) specialist applications breaking is going to stop 
progression of an IETF zeroconf solution, then the WG was never going to 
produce anything, and we should probably transition this to another 
organisation. We should _not_ give up.

Brad

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Jan 2003 19:06:23 +0700

Date:        Thu, 9 Jan 2003 19:45:15 +1100
    From:        Brad Hards <[email-masked]>
    Message-ID:  <[email-masked]>

  | If specialist applications break, then don't run them and zeroconf at
  | the same time.

I think you'll find that this is exactly what Keith wants (leaping to
conclusions here).

The issue is that as currently defined, the only way to "not run them and
zeroconf at the same time" is to "not run them".   That is, zeroconf is
on and stays on always, and there's no way to make it go away - as defined.

What Keith has been requesting (one of the things anyway) is that there be
some nice (relatively) easy way to turn zeroconf off, so it is actually
possible to run applications which may have problems with the existence of
zeroconf addresses.

As I understand them, the existing implementations work exactly that way
anyway - they only configure zeroconf addresses if no other addresses are
available (that is, generally, if dhcp is enabled, and fails).

The WG is insisting that this be altered, and LL addresses always be
configured, and never disabled.    That's one of the major issues.

kre

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jan 2003 08:01:50 -0500

> design error) will ensure that this is the case.

but if the design error is on the part of the zeroconf working group,
we don't give a damn... it's the applications/protocol designers' fault
for assuming that IP would work like it was designed to work.

> I don't care if that happens. 

frankly, I don't care that you think that zeroconf has the right to break
any applications it wants to.   I'm going to do my best to stop it from
doing so.

> organisation. We should _not_ give up.

it's not within the purview of this group to decide which applications
it's okay to break.  zeroconf is NOT chartered to change the Internet
architecture.

if this group can't stay within its charter, then it needs to be shut down.

actually it should have been shut down a long time ago.  the reason that
it's difficult to do so is that it's within episilon of producing something 
useful - and it could do so if it weren't hell-bent on causing problems 
for others.

Keith

---

From: Brad Hards <[email-masked]>
Date: Fri, 10 Jan 2003 01:04:39 +1100

On Fri, 10 Jan 2003 00:01, Keith Moore wrote:
> > _Anything_ that the zeroconf group can do can almost certainly be shown
> > to modify the behaviour of at least one application. Some combination of
I certainly care a great deal. Enough to publish and maintain an 
implementation of part of the technology that we are currently studying.

> any applications it wants to.   I'm going to do my best to stop it from
You have (apparently deliberately) quoted me out of context. What I actually 
said, in part, was: "I don't care if that happens. I _DO_ care if major 
applications break.". The part you have quoted is in relation to "at least 
one application". For the absence of doubt, I do not think that it is OK to 
cause gratitous breakage, but if breaking one specialist application (that is 
probably broken in other common networking scenarios) is the cost of enabling 
IP networking to people who couldn't otherwise have it, then that is a 
reasonable cost.

> > Summary: if one (or a few) specialist applications breaking is going to
> > stop progression of an IETF zeroconf solution, then the WG was never
> > going to produce anything, and we should probably transition this to
> > another organisation. We should _not_ give up.
>
It is absolutely within the purview of this group to change the Internet 
architecture. If we can't change anything, then how can we progress anything? 
That progress may come at the cost of maintenance on some applications, that 
have been programmed with certain assumptions that are not true in general on 
the Internet as it currently exists. That maintenance is worth avoiding, if 
we can avoid it, but I repeat my argument: If you think you can make enough 
changes (whatever they might be), and not have anyone notice that something 
new is happening, then I think further discussion is unlikely to be 
productive.

> useful - and it could do so if it weren't hell-bent on causing problems
If you have specific proposals, please, please, please make them.

I am not saying that the current stuff we have is the right answer. I am quite 
willing to keep working on zeroconf, because I'd like for people like my Mum 
and Dad to be able to use a computer one day. I owe it to them, and lots of 
other people like them, to make that computer use as easy as possible, and 
maintaining the status quo is unacceptable to me.

I think what we have is a much better than the current alternatives of 
requiring network managment in all cases, and that the advantages outweigh 
the theoretical problems, as we currently understand them. There might be 
better options. If someone proposes an alternative, I'll work on that too. 

Brad
- --

---

From: Brad Hards <[email-masked]>
Date: Fri, 10 Jan 2003 01:11:40 +1100

> possible to run applications which may have problems with the existence of
I think that if there is going to be some breakage, then we definately need to 
be able to disable zeroconf on a host-by-host basis.

My recollection of Keith's request was actually that you can disable it on a 
network basis. That is clearly a DoS waiting to happen, and I can't concur. 
There is no precedent (for example, you can't stop all DHCP servers on a 
network basis) and it is unwarranted, given the likely level of breakage 
(minor) and the environment in which it is likely to occur (managed 
networks). Indeed, even if you can disable zeroconf address assignment on an 
per-network basis, you will still likely need to perform some "per-host" 
configuration to enable that machine to communicate in any case.

Again, for the absence of doubt, concur that we should provide the ability to 
disable zeroconf address assignment, on a per-host (and perhaps, 
per-interface) basis.

Brad
- --

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 09 Jan 2003 12:46:38 -0800

> useful - and it could do so if it weren't hell-bent on causing problems

I totally agree...please pick your jaws up off the ground, it's not for the
same reason. Zeroconf is important, but more on an enabling/social level
than on a technological one. We don't need it. But people, (you know, they
buy computers, use AOL, send pictures to grammy, and don't give a rat's
patoot how it happens, but DO hate the work involved to do it) DO need this.

I've come to the conclusion that the IETF is utterly and absolutely
incapable of doing anything for anyone who is not a geek. This is just the
way things are. Apple/Microsoft/IBM and others *are* able to do things for
people who aren't geeks, and I really now firmly believe that they are far
better off telling this group and the IETF to pound sand when talking about
anything that isn't for geeks.

This of course may change, but that would require a too-large sublimation of
ego and pet causes for me to believe that it will prior to the invention of
faster-than-light travel, or the Cubs beating the Red Sox in the World
Series in a 4-game shutout.

john

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

---

From: james mcmurry <[email-masked]>
Date: Thu, 9 Jan 2003 13:00:03 -0800

Hear Hear.

BUT (there always is...)

Apple/Microsoft/IBM/EtAl drive what they perceive their customers want 
(and what will bring the greatest $$ to themselves), and damn the rest 
of the world.  So the IETF (and all of us geeks) do have an important 
role to play in balancing the standards for everyone (including 
non-geeks and my Grandma )

We also need this viscous discussion, to ensure we are doing the best 
thing for everyone (not necessarily the technically preferred way).

All in all, I think zeroconf has done a lot of great things, and we are 
(to steal Mr Moore's words) "within episilon of producing something 
useful".

Jim McMurry
(no company name to put here)

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 9 Jan 2003 21:20:14 -0000

> From: "james mcmurry" <[email-masked]>
> 
> We also need this viscous discussion...

Do you really mean viscous? or vicious? or perhaps vacuous?

Philip

---

From: james mcmurry <[email-masked]>
Date: Thu, 9 Jan 2003 13:24:19 -0800

I meant VISCOUS

Meaning:  Adhesive or sticky

I didn't mean mean Vicious

:)

Sorry

Jim McMurry

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jan 2003 19:36:15 -0500

> IP networking to people who couldn't otherwise have it, then that is a 

well, of course we're not talking about one specialist application.
we're talking about any application that uses IP addresses to do
referrals - a class which includes distributed computation, distributed
simulation, internet telephony, conferencing, multiplayer games.

nor are we really talking about "enabling IP networking to people who 
couldn't otherwise have it".  we're talking about  enabling use of IP
for ad hoc networks.

> It is absolutely within the purview of this group to change the Internet 

utterly irresponsible garbage.  this group was chartered to work on a
narrow problem.  hubris is what is keeping this group from solving that
problem without causing harm.

>If we can't change anything, then how can we progress anything? 

architectural change has the potential to affect a much wider set of
interests than can possibly be represented by this group.  it's
the very ignorance of, and disregard for, the needs of those interests
that makes this group incompentent to try to do architectural change.

> the Internet as it currently exists.

The Internet is far more diverse, both in environments and users needs,
than you seem to imagine.   And your dismissal of the harm done as "cost of
maintenance on some applications" is hopelessly naive. 

> That maintenance is worth avoiding, if 

If you'll look carefully, I haven't been arguing that nobody should notice.
I've been arguing that the v4 spec should include workarounds for the harm 
that v4LL does.  I actually agree that v4LL might be of sufficient benefit
that it's worth some impact to the installed base.  Where I draw the line
is when this group says it's okay to screw some users (and some application
vendors) without giving them workarounds.
> If you have specific proposals, please, please, please make them.

I have made them.  They've been dismissed because people are too insistent
on providing functionality that isn't needed to fulfill the group's charter.

> maintaining the status quo is unacceptable to me.

it's a laudable goal.

however, it's not what this group was chartered to do.
nor does the group appear to have sufficient expertise to credibly work 
on that goal.

nor would v4LL be a step toward that goal.  relative to that goal, v4LL
is a step backwards, because the network that results from v4LL is 
seriously impaired when compared to an IP network with global addresses.
that's not to say that v4LL isn't useful (if some constraints are placed
on its operation) - just that it doesn't address this problem at all.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jan 2003 19:44:05 -0500

On Fri, 10 Jan 2003 01:11:40 +1100
Brad Hards <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

if you have physical access to the network, there are lots of ways to mount
a DoS attack.  having a way for the network to disable v4LL doesn't increase
that vulnerability in any practical sense.

> (minor)

who are you to say that it's a "minor" breakage when someone else's
application fails?

>  and the environment in which it is likely to occur (managed 
> networks).

and who are you to say that it's reasonable to impose v4LL on someone
else's network?  isn't that something that the manager of a network
should be able to decide?

> Indeed, even if you can disable zeroconf address assignment on an 

DHCP doesn't solve all problems, but it seems to work okay for some people.

I think what you're trying to say is that the abliity to disable on a
per-host basis (via host configuration) should be sufficient.  The
reason I don't agree is that I've seen too many network problems result
from some kind of machine not having reasonable defaults and requiring
some explicit configuration.  the "don't you dare plug your machine 
into the network until you've flipped this bit" rule doesn't
scale very well.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 10 Jan 2003 17:13:05 -0800

> problem without causing harm.

Tripe...poppycock. Enough. By creating a standard for v4LL, you are changing
the architecture of the Internet. DHCP did the same thing, as did TCP/IP.

> that makes this group incompentent to try to do architectural change.

I just think the IETF as a whole is incompetent for anything that isn't an
esoteric geek toy.

> maintenance on some applications" is hopelessly naive.

Oh e-bloody-nough. 

I'm going into lurk/autodelete mode on this, and the IETF as a whole. This
isn't a group trying to get anything done as much as its a shouting contest
for geeks. You guys want to argue how many angels can gavotte on a gluon,
continue on. If there is any progress made beyond who is breaking what by
being an incompetent coporate tool, I'll get interested again.

I, like the rest of the world, have *work* to do, on a fairly large scale.
Anymore, I am taking the tack of, if there is a finished standard that can
be used, fine. But I am done waiting for the IETF to finish anything, as I
no longer believe that it is possible on a scale of less than years, and it
is irresponsible to delay work just to appease a collection of people who
have no idea of life outside of the current sheltered environment they are
in.

john

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

---

From: Brad Hards <[email-masked]>
Date: Sat, 11 Jan 2003 12:23:21 +1100

On Sat, 11 Jan 2003 11:44, Keith Moore wrote:
<personal stuff ignored>
> into the network until you've flipped this bit" rule doesn't
In general, I'm not seeing _having_ an IPv4LL address is a major issue to 
causing the type of breakage (that I think) you are concerned about. The 
problem comes when it is used. 

In a managed network, I don't see this as a major issue, because each machine 
will normally need to be configured for other reasons. Whether you do that 
configuration automatically or manually, the incremental work to stop the 
initialisation scripts from assigning an IPv4LL address isn't likely to be 
very great.

There is also precedent work - consider a mixed IPv6 and IPv4 network, where 
all the machines have IPv4 but not all the machines have IPv6.

Not withstanding our differencs in opinion, I'm certainly willing to listen to 
a proposal you have for how we might implement a system that stops IPv4LL 
addresses from being acquired on a network.
I have a couple of ideas (well, implementing an autoresponder that basically 
runs a DoS attack is clearly a option, and would at least work with existing 
implementations, but it might be cleaner if there was also some way of 
reducing the gross network load that this might cause).

Brad

- --

---

From: Brad Hards <[email-masked]>
Date: Sat, 11 Jan 2003 12:39:39 +1100

> simulation, internet telephony, conferencing, multiplayer games.
If that occurs, that clearly isn't good. However IP referal would already seem 
to be broken in certain network situations (NAT, multi-homing, some proxying) 
and I haven't see a coherent explanation of whether the changes that we are 
proposing are going to change the situation in an unacceptable way.

> couldn't otherwise have it".  we're talking about  enabling use of IP
I don't get that interpretation out of the charter, and although ad-hoc is 
clearly a useful area, I think that the intent is substantially wider. Or 
perhaps we just disagree on what "ad-hoc" means.

<ad homium statements ignored>

> on providing functionality that isn't needed to fulfill the group's
We still don't seem to be communicating well. Perhaps it is because the 
problems that you are bringing up are simply not what people want to hear. 
Perhaps it is because you aren't making the issues clearly and unambiguously. 
Perhaps it is a difference of interpretation as to what the group's charter 
is. I'm not sure.

I can only suggest that you try again, perhaps in a different style. For 
example, several people have requested a concrete example of a specific 
network configuration and a specific application that has specific IPv4LL 
breakage that doesn't otherwise occur. Or perhaps an alternative proposal, in 
the form of an I-D.

Brad
- --

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jan 2003 21:08:14 -0500

On Sat, 11 Jan 2003 12:23:21 +1100

> problem comes when it is used. 

right, but if the addresses are exposed to applications (via any of the
means listed in an earlier message) those that don't know any better 
will use them.

it's even more complex than that, though.  v4LL addresses will work
fine with those applications in an isolated ad hoc network, so app
writers will not want to simply refuse to use them.  the case where
v4LL addresses cause problems is when the network is not isolated,
or (similarly) when some hosts on the network think it's isolated
and other hosts have external connectivity.

in trying to deal with a similar problem in IPv6 - use of site-locals,
apparently the best that Microsoft people could do was to have a global
configuration flag for distributed software - are you on an isolated
network or not?  it doesn't seem like a satisfactory solution to me.

> initialisation scripts from assigning an IPv4LL address isn't likely to be 

a DHCP option to disable v4LL would be fine with me if it were required as
part of the v4LL standard.

> all the machines have IPv4 but not all the machines have IPv6.

it's really not the same situation unless you believe that all apps should
speak ipv4 and ipv6 interchangably.  I don't think things will work this way -
I think we'll get apps that interoperate using ipv4 and apps that interoperate
using ipv6 and a few apps that can use either.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jan 2003 21:21:59 -0500

On Sat, 11 Jan 2003 12:39:39 +1100

> proposing are going to change the situation in an unacceptable way.

a crucial difference is that not all IP networks run NATs.   NAT is
(or should be) a voluntary choice made with recognition of the cost vs.
benefit.  the usual compromise for networks of significant size is to put
some things behind a NAT and other things outside of the NAT - or to
nail-up bindings through a NAT so that the servers will have stable
addresses - thereby having (at least in the short term) most of the benefit
of NAT with a minimum cost.  (long term costs are that the network is
not as functional as it should be - and people are starting to realize
this)

by comparison, v4LL is not a choice that a network can make.  it will be
imposed on nearly all networks if it is turned on by default in most 
operating systems.

the fact that NATs have caused harm is not justification for  
zeroconf causing additional harm.

> perhaps we just disagree on what "ad-hoc" means.

I think this is one of the fundamental differences.  It appears that many of
the people in this working group think that the purpose of this working
group is to reduce the amount of configuration necessary to run a network.
Again, it's a laudible goal.   I think the name of the group and the vague
wording of the charter are (in hindsight) very unfortunate because it
conflates two very different problems - how do you reduce the amount of
configuration needed in managed IP networks and how do enable ad hoc IP 
networks without requiring much configuration?

> breakage that doesn't otherwise occur.

the problem is that people will say "but that breaks with NATs too"
never mind that the people who are using those apps now are not using
NATs.  they'll still be forced to use v4LL under the current proposal.

Keith

---

From: Alex Karahalios <[email-masked]>
Date: Fri, 10 Jan 2003 20:18:36 -0700

Sorry Keith, but requiring it as part of the v4LL standard would not be 
fine with me. Require that v4LL depend on DHCP is not in the spirit of 
the draft:

	"It would be beneficial for a host to
	have some useful subset of IP networking that it can depend upon to
	be always functional, even when no configuration information is
	available to the host..."[draft-ietf-zeroconf-ipv4-linklocal-07.txt]

There are devices out there (and I am developing one) that cannot 
afford the extra code burden to make inquiries to a DHCP server.

Alex Karahalios

---

From: Keith Moore <[email-masked]>
Date: Sat, 11 Jan 2003 09:04:06 -0500

On Fri, 10 Jan 2003 20:18:36 -0700

> afford the extra code burden to make inquiries to a DHCP server.

for better or worse, many IPv4 networks use DHCP for host configuration,
and this imposes a minimum burden on devices that want to play on those
networks.

the idea that v4LL is a suitable means to configure a device on a managed
network is another gross violation of this group's charter.

Keith

---

From: Alex Karahalios <[email-masked]>
Date: Sat, 11 Jan 2003 12:20:30 -0700

Hi Keith,

I guess we need to reach a consensus as to whether v4LL should be used 
on a managed network or not. If it's not suitable for a managed 
network, then there would be no DHCP to worry about. Your 
interpretation of the v4LL charter finds v4LL not suitable for managed 
networks. My interpretation is based on the charter statement:

	"Networks where ZEROCONF protocols apply can include (but are not 
limited to) environments where no DHCP, MADCAP or DNS servers are 
present."
[http://www.ietf.org/html.charters/zeroconf-charter.html]

The "but are not limited to" phrase, I think, allows for v4LL to 
coexist with DHCP.

My feeling is that v4LL should be orthogonal to network management 
protocols such as DHCP. There is no need to make them interdependent, 
yet they should still be interoperable on the same wire. This allows 
"dumb" devices to be able to be self configuring via v4LL. "Smart" 
devices can configure themselves using both DHCP and v4LL.

I believe you are seeing v4LL from your own problem domain and you have 
legitimate concerns. I am looking at v4LL from my problem domain, which 
is small embedded devices that have minimal user interfaces that need 
to obtain an IP address without user intervention. DHCP is not a viable 
solution in this case because it does not exist on these networks or is 
too difficult to set up and manage.

As per the ZEROCONF charter, it appears that ZEROCONF (of which v4LL is 
part) is ideally suited to my problem domain. That's why I'm on this 
mailing list.

Maybe we need the IETF to make a definitive statement as to the 
ZEROCONF charter as it pertains to the coexistence of ZEROCONF devices 
in a managed network? Once this is clear (and to me it already is), we 
can properly argue if v4LL is suitable. Maybe you are not questioning 
the existence of v4LL, but rather it's current draft implementation?

Alex Karahalios

---

From: Brad Hards <[email-masked]>
Date: Sun, 12 Jan 2003 10:56:55 +1100

> network is another gross violation of this group's charter.
It is specifically within this groups charter:
<quote>
It is also possible that both modes (ZEROCONF and administered) may coexist on 
the same network; the modes may not be exclusive of each other. 
</quote>

Brad
- --

---

From: Robert Elz <[email-masked]>
Date: Sun, 12 Jan 2003 14:36:34 +0700

Date:        Sat, 11 Jan 2003 12:20:30 -0700
    From:        Alex Karahalios <[email-masked]>
    Message-ID:  <[email-masked]>

  | I am looking at v4LL from my problem domain, which 
  | is small embedded devices that have minimal user interfaces that need 
  | to obtain an IP address without user intervention.

That's fine but ...

  | DHCP is not a viable 
  | solution in this case because it does not exist on these networks or is 
  | too difficult to set up and manage.

That's very poor reasoning.   You're quite correct, DHCP might not be
available, so you cannot rely upon it, and in that case, for some devices
v4LL addresses are likely to be a very good fallback.

But where DHCP is available you really need to use it, even in your very
minimal embedded device.   I suspect that might be more places than
you'd think - lots of cheap hub/switch type devices implement a DHCP
server these days, I have one at home, I'd prefer to disable it, but I
haven't yet found out how, and as it is a "good enough" DHCP server,
I decided just to use the thing instead (it brings one or two minor
advantages over using a "normal" DHCP server on a host - along with
the disadvantages).

A dhcp client for a simple device is really a very trivial piece of code.
And if that proves too much (perhaps lease renewal is just too difficult
for some reason), then you could at least do BOOTP (which is about as
simple as possible to imagine for the client).

Without that, on my net, your trivial devices (whatever they are) are
likely to be useless - I'm very unlikely to connect them (being embedded,
I almost certainly won't get to audit their code) to any net which
has real hosts on it.   If they have some reason for using IP, they must
want to be able to communicate with some other host (perhaps to be controlled
by it, or something) - to do that on my net, the device is going to have
to route through a firewall, for which purpose LL addresses will simply be
useless.

Please don't jump on LL addresses as a solution for baby devices "great,
now I can forget about default routes, redirects, ... I'll just use these,
and these alone, and I'll have that much less code to write".   The
product will be virtually useless.

LL addresses are likely to be just fine for a device to use when it finds
itself in an environment where there are no other available addresses
(ad hoc nets, nets where the dhcp server has failed, ...) to at least
permit some communication to function - they should *never* be viewed as
adequate to always handle any device's networking needs.

kre

---

From: Brad Hards <[email-masked]>
Date: Sun, 12 Jan 2003 18:35:10 +1100

> advantages over using a "normal" DHCP server on a host - along with
The problem with DHCP is that it is pretty critical that you have exactly one 
server. No servers requires IPv4LL as a fallback, two or more servers can 
lead to them handing out conflicting network addresses, subnet masks etc, so 
you can get obscure kinds of breakage. Of course, with the logic that has 
been bandied around here, that would be cause for banning DHCP :-)

Brad
- --

---

From: Alex Karahalios <[email-masked]>
Date: Sun, 12 Jan 2003 11:49:49 -0700

Hi Robert,

Sorry for not making this clear, but in reality the devices I am 
working on actually do have a complete DHCP client implementation. In 
many environments that they are run, however, there are no DHCP servers 
and that is the reason that ZEROCONF looks promising. The DHCP code 
requires about 2K bytes which is about 6% of the of the code space.

The appeal of ZEROCONF is not just the v4LL aspect, but rather the 
entire service discovery mechanism which can be provided by mDNS and 
DNS-SD.

Alex Karahalios

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Jan 2003 01:27:02 +0100 (CET)

[Was: Re: Application software needs to be "zeroconf-aware"?]

> Not withstanding our differencs in opinion, I'm certainly willing to listen
> to  a proposal you have for how we might implement a system that stops
> IPv4LL  addresses from being acquired on a network.

I offer the following straw-man:

There is a "no" vote and a "yes" vote for enabling link-locals
on a link where the "yes" wins over the "no".

The "no" vote is the existence of a DHCP server which hands out addresses.
The "yes" vote is some new protocol mechanism (could be a multicast
query/response, or periodic multicasts).

Thus by default the presence of a DHCP server turns off link-locals.
But, even in the presence of the DHCP server one box on the network
can turn on link-locals.

This means that it isn't easy for somebody to turn off link-locals
when the intent is to turn the on. A rougue DHCP server can't do that, and
an ISP providing DHCP service can do it either - the "yes" vote from the
on-link entity will win.

  Erik

---

From: Brad Hards <[email-masked]>
Date: Thu, 16 Jan 2003 18:27:07 +1100

> But, even in the presence of the DHCP server one box on the network

Some questions, if I may:

What happens in the absence of votes? IPv4LL on?

Is this some kind of "per interface" setup, rather than disabling on a host?

Does the new protocol mechanism default to off? (I assume so, otherwise you 
haven't changed anything)

I assume we are talking about something that can work at the link layer.

How would this look over time? Do we have some kind of "aging" of votes? Any 
thoughts for how long the aging process might take? What happens to a machine 
that has an IPv4LL address, and gets a "NO" vote? Does it die straight away?

Brad

- --

---

From: Luke Diamand <[email-masked]>
Date: Thu, 16 Jan 2003 10:28:37 +0000

What if there is a rogue on-link entity? Won't this have just as bad an 
effect for people trying to disable link-locals?

Luke Diamand

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Jan 2003 08:03:03 -0500

On Thu, 16 Jan 2003 01:27:02 +0100 (CET)

> query/response, or periodic multicasts).

interesting idea.  some questions:

- if the intent of the attacker is to turn *on* v4LL
  (perhaps to facilitate other attacks, given that v4LL weakens security)
  doesn't this make such attacks easier?  in other words, is it 
  reasonable to consider that the risk of an attacker turning off
  v4LL for a DoS attack is a significantly larger threat than that of
  an attacker turning v4LL on for the purpose of a breakin?

  offhand it seems to me like there are security risks with either
  a forged "yes" or "no" signal from the net, and they're both 
  ameliorated in the same way - by monitoring the net for rogue 
  transmitters of such signals.  if you want anything stronger,
  you need authentication, which of course requires host configuration...

- why could the yes vote not be a DHCP response?  is it more reasonble
  to trust a separate mechanism which presumably could be spoofed just
  as easily as DHCP, and which adds complexity?  or is the idea to 
  force the yes vote to be link-local in scope.  (this gets back to the
  security risks of spoofed yes votes - if the spoofing is inherently
  local to the link then it's easier to spoof yes votes without being
  detected - the monitoring has to take place separately for every link)

---

From: Daniel Senie <[email-masked]>
Date: Thu, 16 Jan 2003 09:42:41 -0500

>an ISP providing DHCP service can do it either - the "yes" vote from the

Any mechanism "on the link" which magically turns on link local is 
inherently MUCH MORE EVIL than having it on by default, in my opinion, and 
would be a major step backward. Why? If someone REALLY did want to disable 
LL, you've now provided a way for anyone to plug in (physically or via 
wireless) to a network, and force themselves in by simply yelling out a few 
packets. Very bad idea.

I am willing to entertain a statement in the LL document which states:

"An entity implementing Link Local MAY contain a local configuration option 
to disable LL. Further it MAY contain a local configuration option to 
disable LL only when DHCP is active. However, a mechanism must be present 
on that entity for restoring a factory default in which LL is always on. 
Such mechanism in an embedded system may be a reset button, or on a host 
environment it could be a configuration menu choice.

"In the event LL is disabled by the user using either of these optional 
configuration switches, the user may be unable to establish communications 
with devices which operate solely using LL addressing."

I believe that covers the bases. The configuration MUST be done on a per 
device basis if its to be of any value, IMO.

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 16 Jan 2003 12:06:19 -0800

Is there a reason that we need all these knobs? What's wrong with just 
recommending that an interface only acquire an IPv4LL address if it is 
unable to acquire a global address for an interface? If the device is 
not configured it should use IPv4LL or maybe default to trying DHCP if 
it implements DHCP. If the device has any configuration method and that 
method fails for some reason, the device falls back to IPv4LL.

I think the reason the drafts suggest always acquiring an IPv4LL 
address is historical. The first few drafts suggested that traffic sent 
to an IPv4LL address must always use an IPv4LL source address. When, 
after much discussion, that requirement was dropped, the suggestion of 
always acquiring an IPv4LL was not dropped.

I don't think it makes sense to suggest in the document that devices 
implement an option to disable LL. I think it makes more sense to 
suggest that devices only acquire an IPv4LL address on interfaces where 
DHCP or some other mechanism has supplied an address. Devices with 
global addresses should still be capable of communicating with other 
devices on the same link that only have an IPv4LL. It is not 
inconceivable that a simple device may implement only IPv4LL and not 
DHCP.

-josh

On Thursday, January 16, 2003, at 06:42 AM, Daniel Senie wrote:

> inherently MUCH MORE EVIL than having it on by default, in my opinion, 
> and would be a major step backward. Why? If someone REALLY did want to 
> disable LL, you've now provided a way for anyone to plug in 
> (physically or via wireless) to a network, and force themselves in by 
> simply yelling out a few packets. Very bad idea.
>
> "An entity implementing Link Local MAY contain a local configuration 
> option to disable LL. Further it MAY contain a local configuration 
> option to disable LL only when DHCP is active. However, a mechanism 
> must be present on that entity for restoring a factory default in 
> which LL is always on. Such mechanism in an embedded system may be a 
> reset button, or on a host environment it could be a configuration 
> menu choice.
>
> "In the event LL is disabled by the user using either of these 
> optional configuration switches, the user may be unable to establish 
> communications with devices which operate solely using LL addressing."

---

From: Daniel Senie <[email-masked]>
Date: Thu, 16 Jan 2003 15:55:55 -0500

At 03:06 PM 1/16/2003, Joshua Graessley wrote:

>unable to acquire a global address for an interface?

What's wrong, is that limits the ability to develop a class of devices that 
ONLY operates in the linklocal addressing block. There is a great deal of 
interest in such devices, and, IMO, no good reason to preclude such from 
the market.

>  If the device is not configured it should use IPv4LL or maybe default to 
> trying DHCP if it implements DHCP. If the device has any configuration 
> method and that method fails for some reason, the device falls back to IPv4LL.

So how does your desktop machine, which DID get a DHCP address talk to a 
device which does not support anything but LL addressing? Think about BOTH 
ends of a communication, not just one.

>I think the reason the drafts suggest always acquiring an IPv4LL address 
>is historical.

I disagree.

>  The first few drafts suggested that traffic sent to an IPv4LL address 
> must always use an IPv4LL source address.

Indeed, I'd prefer if we stuck with this, as it would simplify a number of 
matters.

>When, after much discussion, that requirement was dropped, the suggestion 
>of always acquiring an IPv4LL was not dropped.

How does one talk between a DHCP address and a LL address if there's an 
LL-only device? Without a local way to do so, you're cooked. The LL address 
space is NOT supposed to be routed. So it's essential that if an LL device 
is going to talk with a device with a non-LL address, the box with the 
non-LL address must also have an LL address.

>implement an option to disable LL. I think it makes more sense to suggest 
>that devices only acquire an IPv4LL address on interfaces where DHCP or 
>some other mechanism has supplied an address. Devices with global 
>addresses should still be capable of communicating with other devices on 
>the same link that only have an IPv4LL.

HOW? THAT is the issue. You have to do it without a router, which means the 
device with a DHCP or other non-LL address MUST have an LL address to be 
able to communicate.

>  It is not inconceivable that a simple device may implement only IPv4LL 
> and not DHCP.

Precisely. Now work backward with that assumption and think about how 
packets will get between that simple device and a desktop computer.

>>disable LL, you've now provided a way for anyone to plug in (physically 
>>or via wireless) to a network, and force themselves in by simply yelling 
>>out a few packets. Very bad idea.
>>
>>option to disable LL. Further it MAY contain a local configuration option 
>>to disable LL only when DHCP is active. However, a mechanism must be 
>>present on that entity for restoring a factory default in which LL is 
>>always on. Such mechanism in an embedded system may be a reset button, or 
>>on a host environment it could be a configuration menu choice.
>>
>>configuration switches, the user may be unable to establish

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 16 Jan 2003 16:20:13 -0800

On Thursday, January 16, 2003, at 12:55 PM, Daniel Senie wrote:

>> Is there a reason that we need all these knobs? What's wrong with 
>> just recommending that an interface only acquire an IPv4LL address if 
>> it is unable to acquire a global address for an interface?
>
> What's wrong, is that limits the ability to develop a class of devices 
> that ONLY operates in the linklocal addressing block. There is a great 
> deal of interest in such devices, and, IMO, no good reason to preclude 
> such from the market.

I don't see how this precludes such class of products. See below.

>>  If the device is not configured it should use IPv4LL or maybe 
>> default to trying DHCP if it implements DHCP. If the device has any 
>> configuration method and that method fails for some reason, the 
>> device falls back to IPv4LL.
>
> So how does your desktop machine, which DID get a DHCP address talk to 
> a device which does not support anything but LL addressing? Think 
> about BOTH ends of a communication, not just one.

If my desktop machine is LL aware, it should have no difficulty 
communicating with a device supporting only LL addressing. Section 1.7, 
Communication Between Link-Local and Routable Addresses, covers this 
with an example of a laptop with a global address only communicating 
with a web server with a global address to retrieve a page and printing 
that page to a printer with an IPv4LL on the local link.

>> address is historical.

The original argument for requiring link local addresses all the time 
was to communicate with other nodes that may have nothing but a link 
local address. This was necessary because the first drafts required 
that traffic to a link local address have a link local address as the 
source. Without a link local address, you couldn't communicate with 
another node that had only a link local address. That restriction has 
been lifted.

>>  The first few drafts suggested that traffic sent to an IPv4LL 
>> address must always use an IPv4LL source address.
>
> Indeed, I'd prefer if we stuck with this, as it would simplify a 
> number of matters.

Perhaps, perhaps not. If by allowing communication between nodes on the 
same local link with a mixture of global and link local addresses, a 
node only needs one global or one link local address, it also seems to 
simplify things.

>> When, after much discussion, that requirement was dropped, the 
>> suggestion of always acquiring an IPv4LL was not dropped.
>
> How does one talk between a DHCP address and a LL address if there's 
> an LL-only device? Without a local way to do so, you're cooked. The LL 
> address space is NOT supposed to be routed. So it's essential that if 
> an LL device is going to talk with a device with a non-LL address, the 
> box with the non-LL address must also have an LL address.

If both nodes are on the local link, the node with the global address, 
if link local aware, should know to arp for the address instead of 
sending it to a gateway. The node with the link local address knows to 
arp for any address.

>> suggest that devices only acquire an IPv4LL address on interfaces 
>> where DHCP or some other mechanism has supplied an address. Devices 
>> with global addresses should still be capable of communicating with 
>> other devices on the same link that only have an IPv4LL.
>
> HOW? THAT is the issue. You have to do it without a router, which 
> means the device with a DHCP or other non-LL address MUST have an LL 
> address to be able to communicate.

See section 2.6, second paragraph.

>>  It is not inconceivable that a simple device may implement only 
>> IPv4LL and not DHCP.
>

-josh

---

From: Erik Guttman <[email-masked]>
Date: Fri, 17 Jan 2003 09:50:07 +0100 (CET)

> inconceivable that a simple device may implement only IPv4LL and not 

Josh,

I think this is a reasonable direction to pursue.

The arguments for IPv4LL being independent from DHCP configuration are
presented below with some rebuttal.  I present the case from both sides,
leaning to supporting your position. 

 - If a host uses IPv4LL then drops this address configuration when
   DHCP address configuration occurs (which older Macs do, and hosts
   running Windows do), communication with these hosts gets disrupted
   at the time that the DHCP configuration occurs.  Example:  Home
   gateway turned on.

One could argue that if apps have to deal with address reconfiguration
to properly function over IPv4LL, then dealing with transition from
IPv4LL to DHCP configured address should work too.

 - There are environments in which DHCP doesn't work (more than one 
   DHCP server is running at once).  It would be nice if local 
   communication could continue in this case.  Example:  Some geeky
   households have a cable modem, a home gateway, a... which can 
   mean more than one DHCP server.

One could argue that such a case is disfunctional and should never occur
in reality.  It does occur, but even then, it lasts only as long as it
takes to turn off the undesired server(s).

 - Hosts will reconfigure at different times due to DHCP, so there may
   be a period in which one host will have IPv4LL and another will not.

This is inconvenient, but not fatal.

 - If there are some hosts which use IPv4LL only, others have to support
   IPv4LL to communicate with them, in any case.  

This support may be limited to support for a stack to use ARP to resolve
addresses in the LL range, and forward traffic to the link instead of to
a router.

Am I missing anything?

Erik

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Jan 2003 09:28:44 -0500

> been bandied around here, that would be cause for banning DHCP :-)

or fixing it.  but that's not a topic for this working group.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Jan 2003 09:39:46 -0500

> wireless) to a network, and force themselves in by simply yelling out a few 

so which is worse:

a. a denial of service attack from a local attacker by disabling v4LL
b. an attack on a host from a local attacker facilitated by enabling v4LL
c. an attack on all IPv4 networks from the zeroconf working group

I'd vastly prefer either a or b to c.  At least a and b are limited in scope. 
And it's ridiculous to consider threat a while ignoring threat b.

> I am willing to entertain a statement in the LL document which states:

That's nice of you.  IMHO, a more appropriate statement would be:

The zeroconf working group is being abandoned due to gross violations of its
charter and failure to produce a document which meets the criteria for
proposed standard in RFC 2026.  

Now will you please stop pretending that you have the right to impose this
stuff on every host in the Internet?

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Jan 2003 09:43:37 -0500

On Thu, 16 Jan 2003 15:55:55 -0500

> interest in such devices, and, IMO, no good reason to preclude such from 

this is not in the group's charter. and it's ridiculous to assume that any
device only needs to talk to other devices on its local network segment.
it's even more ridiculous to demand that every IPv4 host that wants to support
zeroconf be configured by default to be able to talk to such dysfunctional
devices.

> ends of a communication, not just one.

maybe I don't want my desktop machine to talk to dysfunctional devices.
who are you to insist that it should be configured to do so by default?

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 17 Jan 2003 11:06:28 -0500

> proposed standard in RFC 2026.

Okay, can we all admit that we are now going so far into personal causes
that it's going to be impossible to do any work until such time that we can
separate ego and personal issues from the idea of actually getting stuff
done.

But if we do disband this, I propose this text:

The zeroconf working group is being abandoned due to gross violations of its
charter and failure to produce a document which meets the criteria for
proposed standard in RFC 2026. As well, the IETF should abandon any efforts
to standardize anything that has to do with ease of use, or human issues due
to a complete inability to understand that the vast majority of computer
users don't know, don't care to know, and never will want to know how their
computer does anything at all.

john

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

---

From: "Bill Rees" <[email-masked]>
Date: Fri, 17 Jan 2003 13:41:43 -0800

----- Original Message -----
From: "John C. Welch" <[email-masked]>
Subject: Re: Turning off link-locals?

> c. an attack on all IPv4 networks from the zeroconf working group

The answer is "D:  refusing to address the need for self configuring
networks which require at most automated administration".  This answer also
answers your statement that ...
> computer does anything at all.

The zeroconf wg is tied to Rendezvous as an answer to D: so the defacto
vendor view of the working group is of a group of people focusing on D: and
making sure whatever solution standardized that the goal of
self-configuration or aut-configurtion is met. Otherwise there is no reason
for this working group to exist.  Besides, (And I for once am thankful of
Apple) if zeroconf strays from Apple's interpretation of the charter then
Apple will solve the problem without us and create a defacto standard
regardless of anyone's concerns expressed in this group.

This interpretation argues for v4LL default to on, that some sort of
propaganda concerning how the device works in a DHCP environment to contain
v4LL problems (prefer static over  DHCP over v4LL) and anything issues
blocking this goal which defy address within this email's interpretation of
the charter must be handled as addendums or errata or appendices or
recommendations for best practices.  Anything else is beyond the vendor
defacto intrepretation of the charter.

Get over it and either recharter the working group or take Rendezvous as the
guide for standardization.

Bill

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Jan 2003 17:02:56 -0500

> > so which is worse:
> >
> > a. a denial of service attack from a local attacker by disabling
> > v4LL b. an attack on a host from a local attacker facilitated by
> > enabling v4LL c. an attack on all IPv4 networks from the zeroconf
> > working group
> >
>
> networks which require at most automated administration".  

v4LL doesn't address that need at all. The most it does (regarding self-configurating networks) is shift the burden from network configuration to host and application configuration. 

If you want to build self-configuring networks, you need to first understand the broad spectrum of requirements which the network will be required to support - the needs of users, applications developers, network administrators, and those concerned with security.  Then you can develop an architecture that recognizes all of those needs as legitimate and incorporates provisions to satisfy those needs.

Pretending that a technology that allows use of scoped addresses on ad hoc networks will work fine on managed networks and with the great diversity of applications in use, is not furthering your stated goal -- it's hindering it.  The sooner this approach is abandoned the sooner real progress can be made.

> The zeroconf wg is tied to Rendezvous as an answer to D: 

I don't believe you.  But to the extent people believe Rendezvous solves these problems, it's not hard to understand why the group is having so much trouble making progress.

Keith
-- 
I tried enlightenment but it kept crashing.

---

From: "Bill Rees" <[email-masked]>
Date: Fri, 17 Jan 2003 14:23:59 -0800

----- Original Message -----
From: "Keith Moore" <[email-masked]>
> v4LL doesn't address that need at all. The most it does (regarding
self-configurating networks) is shift
> the burden from network configuration to host and application
configuration.

Well rendezvous has done a good job addressing this problem since it appears
to work so far.  If you state the v4LL by itself will solve these problems
than I agree with you.  In that case you

>
> If you want to build self-configuring networks, you need to first
understand the broad spectrum of requirements which the network will be
required to support - the needs of users, applications developers, network
administrators, and those concerned with security.  Then you can develop an
architecture that recognizes all of those needs as legitimate and
incorporates provisions to satisfy those needs.
>
> Pretending that a technology that allows use of scoped addresses on ad hoc
networks will work fine on managed networks and with the great diversity of
applications in use, is not furthering your stated goal -- it's hindering
it.  The sooner this approach is abandoned the sooner real progress can be
made.

> I don't believe you.  But to the extent people believe Rendezvous solves
these problems, it's not hard to understand why the group is having so much
trouble making progress.

Well I certainly feel foolish here since I came to the zeroconf wg via an
Apple pointer from the rendezvous page, right next to the text talking about
rendezvous' connection with zeroconf.  Unfortunately, I leapt to the
conclusion that the association with rendezvous meant the zeroconf name was
zero-configuration and had zero-configuration as its goal.

If I'm off base then I'll cease to think of zero-configuration as a goal for
zeroconf.  Since the problems apparent within v4LL probably require a series
of standard-draft responses to address the zero-configuration goal, a clear
disparity needs expressing relative to rendezvous so noone else mistakenly
makes this connection (as I foolishly and naively did).

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Jan 2003 19:13:25 -0500

> > self-configurating networks) is shift the burden from network
> > configuration to host and application configuration.
> 
> Well rendezvous has done a good job addressing this problem

no it hasn't. rendezvous doesn't give the host a stable global IP address. 
rendezvous can't tell an application which of several addresses works best to
reach some random host, or whether or not some random host is the same 
addressing realm as either the caller or some other random host.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 17 Jan 2003 19:25:33 -0500

> regardless of anyone's concerns expressed in this group.

Excellent! This is an excellent point. Zeroconf is *not* like IPv6, where it
was created by the IETF. Zeroconf is/will be/hopefully will be the standard
behind things like Rendezvous, etc. But, those things will happen, and be
implemented with or without the IETF. Which is why I'm rather strident that
we can't afford to spend months on vague possibilities...if it's a real,
repeatable problem, great, document it, post it, let's fix it and move on.
Otherwise, it's a "what if..." and those don't count.

john

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

---

From: Robert Elz <[email-masked]>
Date: Sat, 18 Jan 2003 16:56:02 +0700

Date:        Thu, 16 Jan 2003 15:55:55 -0500
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | What's wrong, is that limits the ability to develop a class of devices that 
  | ONLY operates in the linklocal addressing block.

I can't even begin to imagine why anyone would even consider making
applications (or devices) which care what the bit pattern in an address
is.   That's truly bizarre.   Changing even a comma in a doc to make
that kind of device plausible (or easier) isn't worth the effort.

  | So how does your desktop machine, which DID get a DHCP address talk to a 
  | device which does not support anything but LL addressing? Think about BOTH 
  | ends of a communication, not just one.

This is beyond trivial.   Assuming the device with the DHCP address is
LL aware (dealing with devices older than LL, or which choose to ignore
it is a different problem) then it simply "knows" that LL addresses are
local to the (appropriate) link.  And ARPs for them.   This is no different
in concept to 127/8 addresses that hosts simply "know" are internal.

Devices that have only LL addresses should simply ARP for everything
(the LL address block serves to bound the possible addresses that can be
locally assigned, but every address is otherwise treated as LL).

So?   Where is the difficulty?

  | So it's essential that if an LL device 
  | is going to talk with a device with a non-LL address, the box with the 
  | non-LL address must also have an LL address.

Rubbish.   Did you even read any of Christian's messages?
We don't even need LL aware equipment (in some cases) to make
this work, if there's only one interface, just about any
(configurable) IP stack can be told that any random address
block is directly reachable, and so to simply ARP for it.

I kind of like Erik's suggestion (Erik N's).   I'm not much worried by
the "rogue broadcaster" problem, nets subject to those problems have
much worse things to worry about.   If it was an accident, then it gets
fixed, and everyone learns a little.   If it was deliberate, then I'd
also expect arp spoofing, etc, which is a much bigger worry.

But I also can't see any reason why if "dhcp" is the "off" switch for
LL addresses, that dhcp can't also be the "on" switch.   That is if
the dhcp includes an option "retain your LL addr", the host keeps it,
otherwise, it gets rid of the thing (and most of the time, what that
means, is that it never gets one at all).

The only real issue that needs work this this is in how to deal with
devices that were using LL addresses when they're told to stop.   Just
breaking connections is not a great answer.   Can this WG not just copy
v6 deprecated addresses though?   That is, allow the LL address to
continue to be used, but only for existing connections (in the broad
sense of the term - including UDP applications, etc).   After the global
addr (or 1918 addr...) is acquired, the host would stop advertising its
LL addr, and would no longer use it when initiating new connections.

For knobs, I think one is enough.   I don't see a need for Christian's
knob #2.   I can't think of any plausible reason why a host would want
to prohibit itself from talking to other nodes, just because they're
using LL addresses.   Or not only that.   That is, nodes that like to
filter communications based upon address are likely to want more
functionality than allow LL/disallow LL.   If the host has some kind of
general address filtering mechanism, to control with whom it will engage
in dialogs, then that mechanism will serve just fine to allow/block LL's.
If it doesn't, I doubt it really needs one specially just for LL's.

kre

ps: there seems to be a difference of opinion here as to whether the
current drafts forbid communications between LL and non LL addresses.
If they do, that needs to be fixed.

pps: has (or will) this WG spend any time on considering what the API
ought to be like to allow hosts with more than one interface operate
when LL addresses exist on both?   One would assume that such methods
must exist, Apple ibooks have both wireless and wired nets built in,
don't they (as do numerous other laptops)?  Their apps have to be able
to cope somehow?   How?

---

From: Keith Moore <[email-masked]>
Date: Sat, 18 Jan 2003 08:28:45 -0500

> means, is that it never gets one at all).

That makes sense to me also. 

> LL addr, and would no longer use it when initiating new connections.

This isn't perfect, but it will work more often than anything else that has
been proposed.  Apps that get started on an isolated network and later acquire
routable addresses may get confused -- but this should be rare and in most
cases preventable. 

(The devil is in details like if and how the deprecated address shows up in 
ioctl SIOCGIFCONF.)

> using LL addresses. 

For better or worse, DHCP is sometimes used as an access control mechanism.  a
host that doesn't have its MAC address registered with the DHCP server cannot
get an IP address.  If a host without an assigned IP address can still talk to
other hosts on the local link using LL, this breaks the security measures that
are in place on that link.  Perhaps it's a lame security measure, but sites
are using it because it's the best thing that is available and that works
without host software changes.  So I do think there's a good argument
for the second knob, to tell hosts "don't talk to LL addresses".

Keith

p.s. For the case of talking between a host with an LL address and a host with
a routable address: I don't see a good justification for LL-only hosts, so I'm
not sure why we need to consider this case - if the LL-only host can't get a
routable address via DHCP or BOOTP then it is presumably a matter of site
policy -- and I don't think using BOOTP to get a routable address is an
onerous implementation requirement.  But assuming there is a justification for
it, it makes more sense for the functional host to use a routable address than
to use an LL address, simply because the more LL addresses that are in use,
the more problems result (addresses leaking outside their scope,collisions,
multiple interface ambiguity, security, etc.).

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Jan 2003 00:56:49 +0100 (CET)

> Some questions, if I may:

Sure, but I did say "strawman" so I don'r have the all the answers.

> What happens in the absence of votes? IPv4LL on?

Yes.

> Is this some kind of "per interface" setup, rather than disabling on a host?

Yep.

> haven't changed anything)

Do you mean the new protocol for sending "yes" votes? That needs
to default to off. But it might be reasonably for boxes that only function
as home gateways to by default vote "yes" with the ability to turn this off.
Even if that is done this voting scheme prevents lots of boxes in lots
of environments to have both a v4ll address and a dhcp assigned address.

> I assume we are talking about something that can work at the link layer.

I don't understand the question. I don't want the "yes" vote protocol
to cross routers - accidentally or intentionally. But it can still be
implemented on top of IP. (For instance, if we do the "send with ttl=255
and verify ttl=255 on receipt and send to a link-local multicast address
i.e. 224.0.0.0/24)

> thoughts for how long the aging process might take? What happens to a
> machine  that has an IPv4LL address, and gets a "NO" vote? Does it die
> straight away?

Those are good questions to work on. 

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Jan 2003 00:59:28 +0100 (CET)

> effect for people trying to disable link-locals?

An on-link entity can force v4ll on even in the presence of a dhcp server.
I don't see a mechanism (short of additional configuration) that can
avoid this given that we don't want to trust the DHCP infrastructure
to make the yes/no choice. (Old discussions about this and the desire
to want to use v4ll even if the ISP providing the DHCP responses might
be of a different opinion.)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Jan 2003 01:08:37 +0100 (CET)

> interesting idea.  some questions:

We live in interesting times...

>   an attacker turning v4LL on for the purpose of a breakin?

I think the only way you can deal with an attacker on the link
is to be able to turn off v4ll manually on each host.
The strawman is trying to capture a hopefully common case when
the devices that are connected to the link are reasonably trusted.

But if there are attacks that can not be exploited by an on-link attacker
when the target only has a dhcp assigned address, but can be exploited
by an on-link attacker when the target has a v4ll and a dhcp assigned 
address, then the strawman has a significant downside.
But such setups seems odd, since such an attackable target would have to 
associate security properties not with whether or not the peer address
is on the subnet, but whether or not the peer address is a v4ll.
Such a device would work differently in an environment that doesn't
have v4ll configured (likely for an office setting for instance).

Yep.

>   detected - the monitoring has to take place separately for every link)

Concerns that the operator of the DHCP infrastructure (a different
adminstrative entity than the operator of the hosts in some cases) would have
conflicting goals with the operator of the local link.
We had those discussions around the proposed dhcp option that would
control whether or not v4ll was used.

But the intent is that the "yes" votes be local to the link.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Jan 2003 01:13:52 +0100 (CET)

> wireless) to a network, and force themselves in by simply yelling out a few 

How could it be worse than having it on by default with no mechanism
to turn it off?

The strawman allows per-host controls to override the "yes" vote, but
even if they don't exist (due to hosts without any local knobs)
and there is an attacker on the link, it results in it being on.

> device basis if its to be of any value, IMO. 

Because you don't think the local link should be trusted at
all?
I'm contrasting this with other old statements on this list
that v4ll is good since it simplifies security configuration - the v4ll
address are known to be on the (trusted) local link.

I'm confused.

  Erik

---

From: Robert Elz <[email-masked]>
Date: Sun, 19 Jan 2003 16:36:15 +0700

Date:        Sat, 18 Jan 2003 08:28:45 -0500
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | (The devil is in details like if and how the deprecated address shows up in 
  | ioctl SIOCGIFCONF.)

Yes, the API questions of all of this currently seem to be being ignored.

  | For better or worse, DHCP is sometimes used as an access control mechanism.

That's so utterly bogus that I don't care in the slightest if it gets
"broken"  ("broken" in quotes, as it is already broken).   If using
LL addresses helps make people more aware how non-existant any "security"
of that form is, then I'd count it as a feature, not a bug.

Of course, hosts that want to avoid talking to LL addresses, or net 10
addresses, or anything else, should be able to be configured to do that.
On the local lan, this is still no kind of "security" as anything attempting
to intrude can simply allocate itself an address in the authorised range.

That is, forbidding this kind of communication adds zero security.

If all that's relevant is the incentive to go register the MAC address,
then confining communications on the LAN should be good enough - those
few servers that give the illusion of allowing wider access (web proxy servers
etc) can be configured to refuse to serve LL addresses, if that's the
desire.

  | p.s. For the case of talking between a host with an LL address and a host
  | with a routable address: I don't see a good justification for LL-only hosts

Not only do I not see a good justification, I see no justification at all.
In fact, such a "host" I would regard as flat out useless.   What good
is something that can't communicate where it needs to?   And how can the
manufacturers of any host possibly know the net topology I will be
installing it into?    They may like to assume that everything relevant
will be on the same lan, and many times it might be, but it certainly
won't always be.   If there was a way to ban such things, I'd do it.

I was just responding to the bogus assertion that devices have to have
LL addresses in order to talk to some other device which might only have
an LL address - which could happen even for sane hosts during a transition
period when global addresses are just becoming available - not every host
will acquire its global address at the same time.

kre

---

From: Keith Moore <[email-masked]>
Date: Sun, 19 Jan 2003 10:23:49 -0500

On Sun, 19 Jan 2003 01:08:37 +0100 (CET)

> is to be able to turn off v4ll manually on each host.

why not to turn it either off or on manually on each host?  in other words,
why consider one kind of attack more of a threat than the other? 

> the devices that are connected to the link are reasonably trusted.

at best this only works for wired links.

> > - why could the yes vote not be a DHCP response?  
> adminstrative entity than the operator of the hosts in some cases) would
> have conflicting goals with the operator of the local link.

mumble.  ISPs, LAN operators, link operators, host operators, users, and code
developers are all potentially different parties with sometimes-conflicting
interests.  how much is it the job of this WG (or any IETF WG) to facilitate
their competing with each other?

---

From: Keith Moore <[email-masked]>
Date: Sun, 19 Jan 2003 10:29:58 -0500

On Sun, 19 Jan 2003 16:36:15 +0700
Robert Elz <[email-masked]> wrote:

>   | (The devil is in details like if and how the deprecated address shows up
>   in | ioctl SIOCGIFCONF.)
> 

I suspect that if we break it it's more likely to be replaced with something
worse, than with something better.

I also think that it's perfectly reasonable for a LAN operator to impose
policy on how that LAN can be used, for whatever reasons the LAN administrator
happens to think are valid, and that includes down to the link level.  The
administrator's logic might be flawed, his/her values might be twisted, but
that's not for this group to decide.  Nor is it for this group to decide that
the mechanisms chosen by the LAN administrator to implement that policy are to
be discarded.  I don't think zeroconf can reasonably declare "it's okay to use
LL addresses on any link" by fiat.

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Jan 2003 22:37:38 +0100 (CET)

> why consider one kind of attack more of a threat than the other? 

Depends what defaults people can roughly agree on.
Some folks want to be conservative and have v4ll be off by default.
Others want things to work out of the box by having v4ll be on by default.
(Of course, things are a bit more tricky since we have on/off when
there is no dhcp service as well as on/off when dhcp is handing out
addresses.)

If the WG can't come to rough consensus on the defaults and
is concerned about devices with no user-configurable parts inside,
then it makes sense considering the strawman as a way to allow
some other device on the link control this behavior.

> at best this only works for wired links.

Yep, unless 802.11 security is more widely used. But currently
it is both to hard to configure and too insecure.
 
> their competing with each other?

The "tussle" paper (I think "Tussles in cyperspace ..." is the title)
argues that it makes sense modularizing along tussle boundaries. I think
this means allowing the tussle to play out without having to modify the
protocols.

  Erik

---

From: Robert Elz <[email-masked]>
Date: Mon, 20 Jan 2003 16:19:25 +0700

Date:        Sun, 19 Jan 2003 10:29:58 -0500
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | I also think that it's perfectly reasonable for a LAN operator to impose
  | policy on how that LAN can be used, for whatever reasons the LAN
  | administrator happens to think are valid, and that includes down to
  | the link level.

Absolutely, I don't object to that at all.   However having us pretend to
the administrator that "if your dhcp server doesn't answer those people
you don't know, they'll be shut off your LAN" doesn't help.   What's
needed is for proper education about the nature of LANS - if you can
connect to it, you can talk to it.   The LAN (or the ones we're mostly
concerned with) is a passive device.

[Aside: I know there are active devices that can be stuck in the middle
of a LAN, and that some of them pretend to arbitrate access, none I have
yet seen takes more than a few minutes to breach though, if you're able
to get physical connectivity.  If anything, WEP is probably one of the
hardest of the lot (which is saying something), most of what's left just
needs MAC addr spoofing to defeat.]

If this ...

  | I don't think zeroconf can reasonably declare "it's okay to use
  | LL addresses on any link" by fiat.

was your main point here though, then I agree, and we need a way to
turn the things off (we even seem to be approaching some kind of WG
agreement perhaps, as they didn't seem to be any "NO, not acceptable"
responses to Erik's suggestion - just questions of the mechanisms).

But I don't think it gains anything to have a setting that says "LL
addresses are OK on this link, but they can't be used to talk to hosts
on the link that happen not to have an LL address".   That's not a
policy that it makes any sense to maintain.   Some individual host
might want to implement a policy like that, which is fine, but we
don't really need to add mechanism to make it a network default policy.

kre

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 06:46:13 -0500

On Mon, 20 Jan 2003 16:19:25 +0700
Robert Elz <[email-masked]> wrote:

> you don't know, they'll be shut off your LAN" doesn't help. 

I don't think the admins are that deluded.  They know that a rogue host can
try choosing an address without DHCP, but this will be defined as antisocial
behavior.  On the other hand, for IETF to say "don't worry about the LAN
admin, it's okay if you use LL addresses on that link, and all the vendors
will ship code that implements this" circumvents the policy.

> to get physical connectivity.  

We should not assume that the admin's goal in requiring MAC address
registration is perfect security, any more than we should assume that the
person who installs a short fence around a building thinks that nobody will
climb over it or cut through it.  The purpose in both cases is to discourage
penetration and to marginalize those that do.  Often this is sufficient,
especially when coupled with other measures such as penalties and visibility.

> on the link that happen not to have an LL address". 

I guess I haven't seen much value in that myself.

Basicaly I think that LL addresses should be used only in ad hoc or isolated
networks.  If a LL-capable device is connected to a managed network, it should
get an address from that network - then it can be assured of getting an
address of appropriate scope for its purposes, as the scope is controlled by
the network rather than by the device.  If the network is set up to require
registration of all devices, then it should require registration for the
LL-capable device also.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 20 Jan 2003 10:04:10 -0500

> registration of all devices, then it should require registration for the

There are situations, and fairly common ones where you don't want this. For
example, MIT requires MAC - address registration for all wireless access. If
you work/got to school at MIT, no big deal.

But, for consultants, temp workers, people coming in to do presentations for
a single shot purpose, this requirement is now quite the pain in the heiny,
because it takes multiple phone calls to get the temp access approved. This
access doesn't give you certificates or a Kerberos UserID, so it's not even
close to a security issue.

*That* situation, fairly common, is why you want LL on, even in the presence
of DHCP. 

Look, it may be annoying, but again, single - link multihoming is used
daily, it hasn't broken doodly squat in the years it's been being used.
There's no case for saying that's a problem. Some routers may need to be
checked to ensure that they don't pass LL addresses, but they shouldn't be
*anyway*, so there's no great reconfig needed there, unless you have already
broken your router.

With proper security, LL will cause you no problems by its existence, and
there are good reasons to leave it on even in the face of other
configuration methods.

john

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 10:34:28 -0500

On Mon, 20 Jan 2003 10:04:10 -0500
"John C. Welch" <[email-masked]> wrote:

> > Basicaly I think that LL addresses should be used only in ad hoc or
> > isolated networks.  If a LL-capable device is connected to a managed
> > network, it should get an address from that network - then it can be
> > assured of getting an address of appropriate scope for its purposes,
> > as the scope is controlled by the network rather than by the device.
> >  If the network is set up to require
> > registration of all devices, then it should require registration for
> > the LL-capable device also.
> 
> There are situations, and fairly common ones where you don't want
> this. For example, MIT requires MAC - address registration for all
> wireless access. If you work/got to school at MIT, no big deal.
> 
> But, for consultants, temp workers, people coming in to do
> presentations for a single shot purpose, this requirement is now quite
> the pain in the heiny, because it takes multiple phone calls to get
> the temp access approved. This access doesn't give you certificates or
> a Kerberos UserID, so it's not even close to a security issue.
> 
> *That* situation, fairly common, is why you want LL on, even in the
> presence of DHCP. 

no, it doesn't follow, because

- LL access wouldn't solve the problem for temp users anyway, because they're often going to need access beyond the local link

- Apparently MIT doesn't want users to use the network without being registered.  Use of LL would circumvent that policy.   I think that the policy for MIT's networks should be set by MIT.  If their policy or the implementation thereof is too onerous, that may be unfortunate, but it's not a problem for IETF to solve.

- Technical means are already available which would allow MIT's DHCP servers to grant temporary network access to temporary users, with appropriate bandwidth/routing limitations on such use.  (If the University of Tennesse can do this I'm sure MIT can manage it.)

---

From: Brad Davis <[email-masked]>
Date: Mon, 20 Jan 2003 09:24:33 -0700

Robert Elz wrote:
> What's

This is (I think) the heart of the arguments.  Keith is worried about the impact 
of this protocol on LANs that aren't part of the set that "we're mostly 
concerned with".

Most "good" protocols are used far beyond what their creators imagined.  We must 
be concerned with the impact of LL addresses outside the scope of how this WG 
expects them to be used.  I think that the intent of this protocol will be 
butchered.

 >registration of all devices, then it should require registration for the

I agree with this.  I also think that this group should put together a "best 
practices" document that defines a DHCP/DNS(/others?) network that is 
preconfigured to support as close to zero configuration as can be done.

Brad Davis

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 20 Jan 2003 12:21:58 -0500

On 01/20/2003 10:34, "Keith Moore" <[email-masked]> wrote:

> - LL access wouldn't solve the problem for temp users anyway, because they're
> often going to need access beyond the local link

In 80-90% of cases, what they need is a way to print, or get files to a
machine in the same room.

> 
> - Apparently MIT doesn't want users to use the network without being
> registered.  Use of LL would circumvent that policy.   I think that the policy
> for MIT's networks should be set by MIT.  If their policy or the
> implementation thereof is too onerous, that may be unfortunate, but it's not a
> problem for IETF to solve.

I'm not *saying* that the IETF needs to solve MIT's problems. That would
take decades. I'm *saying* that there is a need for LL to run even with
other address management going on. To the point, MIT doesn¹t much care about
LL, as long as you aren't messing up the rest of the network, which hasn't
been happening, and there are a lot of folks using it.

> 
> - Technical means are already available which would allow MIT's DHCP servers
> to grant temporary network access to temporary users, with appropriate
> bandwidth/routing limitations on such use.  (If the University of Tennesse can
> do this I'm sure MIT can manage it.)

Right...set up an IP address, track it, disable it, for a consultant to
transfer a couple of PDFs...how efficient.

john

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 14:53:25 -0500

> > - LL access wouldn't solve the problem for temp users anyway,
> > because they're often going to need access beyond the local link
> 
> In 80-90% of cases, what they need is a way to print, or get files to
> a machine in the same room.

your temp users must be different than ours.  lots of ours want to check their email, or to download files.

> > registered.  Use of LL would circumvent that policy.   I think that
> > the policy for MIT's networks should be set by MIT.  If their policy
> > or the implementation thereof is too onerous, that may be
> > unfortunate, but it's not a problem for IETF to solve.
> 
> I'm not *saying* that the IETF needs to solve MIT's problems. That
> would take decades. 

> I'm *saying* that there is a need for LL to run
> even with other address management going on. 

and I'm saying that neither you nor this working group has any business dictating to a LAN administrator that he or she "needs" for LL to circumvent his/her existing address management or network access policies.

> To the point, MIT doesn¹t
> much care about LL, as long as you aren't messing up the rest of the
> network, which hasn't been happening, and there are a lot of folks
> using it.

perhaps not, but I assure you that other institutions do care about controlling access to their LANs.

> > - Technical means are already available which would allow MIT's DHCP
> > servers to grant temporary network access to temporary users, with
> > appropriate bandwidth/routing limitations on such use.  (If the
> > University of Tennesse can do this I'm sure MIT can manage it.)
> 
> Right...set up an IP address, track it, disable it, for a consultant
> to transfer a couple of PDFs...how efficient.

let me put it another way - if MIT can't solve the problem more simply than that, perhaps they need to hire some more clever network engineers.
-- 
I tried enlightenment but it kept crashing.

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 20 Jan 2003 16:48:57 -0500

> email, or to download files.

Then you give them a DHCP address too. Where's the problem with both as
appropriate? And no, it's not breaking a network, it's not going to invite
every cracker on the planet in either.

> and I'm saying that neither you nor this working group has any business
> dictating to a LAN administrator that he or she "needs" for LL to circumvent
> his/her existing address management or network access policies.

How is LL circumventing *anything*? You keep nattering on about this, but
quite honestly, it's not an issue. You have this oddly limited idea of how
something is useful, and seem to reject anything that is outside that idea.
You have yet to show where the simple existance of an additional LL address
is going to break something, and you can't, because if it did on the scale
you imply, then multiple addresses on an interface WOULD.NOT.WORK. But since
they do, even when they are in entirely different networks, then your issues
with this are invalid. As well, I *also* don't think the WG has any business
creating a configuration method that is set up as to be inherently
untrustworthy, and open to abuse...if all I have to do is act like a DHCP
server to kill every LL device that can see me, then LL is useless.

> controlling access to their LANs.

Oh, MIT cares about that quite a bit. But they also are wise enough to
understand that there are times when you just need to print real quick,
transfer a file, and there's no real point in forcing an entire
registration/deregistration process for five minutes of work.

> let me put it another way - if MIT can't solve the problem more simply than
> that, perhaps they need to hire some more clever network engineers.

Oh, we're plenty clever. But we also don't allow any fool with a wireless
card to get a DHCP address and become part of the network without
registering the MAC address. You want DHCP, that's how you get it. You want
access to data, then you need SSL and Kerberos access. But again, you lead
the discussion off track *again*, this time by making MIT network ops an
issue. *do* stay on point, hmm?

john

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 17:01:40 -0500

> appropriate? 

Whether LL is appropriate depends on the needs of the user, the needs of the
application, and the policies of the network on which it would be used.  It
has nothing to do with what you want.

> > dictating to a LAN administrator that he or she "needs" for LL to
> > circumvent his/her existing address management or network access policies.
> 
> quite honestly, it's not an issue.

It's not for you or this working group to decide whether it is an issue.

> You have this oddly limited idea of how

No, I reject your trying to declare by fiat that whatever random idea you
think is good for the world should be imposed on the world by overloading
existing interfaces -  and whatever breakage occurs as a result (be it apps or
security or whatever) well, that's either somebody else's problem, or somebody
else's fault for not doing things the way you think they should be done.

> you imply, then multiple addresses on an interface WOULD.NOT.WORK. 

Multiple addresses on an interface are rarely used in IPv4, except on
dedicated servers to support virtual hosting, precisely because they break
things if apps have to be clever about which addresses to use in which
circumstances.   But multiple global addresses cause few problems because the
app generally works no matter which address is chosen.  OTOH, scoped addresses
cause lots of problems.

> As well, I *also* don't think the WG has any business
> untrustworthy, and open to abuse...

Good, then we agree that this WG has no busines creating LL, because LL is
inherently untrustworthy and open to abuse.  (of course, you want to define
what trust and abuse mean for other people's networks.)

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 20 Jan 2003 18:09:29 -0500

> has nothing to do with what you want.

Right...but *I* am saying, let it be there, *you* are saying, "To heck with
what the user might need, if DHCP exists, turn LL OFF, and keep it off,
regardless of need."

> It's not for you or this working group to decide whether it is an issue.

It's not for you to decide that either.

> else's fault for not doing things the way you think they should be done.

Oh please, get a grip. If you don't like multiple IP's for interfaces, then
you have a lot of windmills to tilt at.

> app generally works no matter which address is chosen.  OTOH, scoped addresses

So they're rarely used except when they're used a LOT...there's a paradox
for you. And multiple addresses of different scopes don't have problems
unless the app tries to circumvent the OS and get clever on it's own.

> what trust and abuse mean for other people's networks.)

No, *you* want to torpedo LL. I think that it's a noble, and good idea. But
then, I think that networking should be easy NOW, not at some point in the
random future. You still think that only geeks should be able to set up
networks.

john

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

---

From: Joshua Graessley <[email-masked]>
Date: Mon, 20 Jan 2003 15:38:08 -0800

> zeroconf be configured by default to be able to talk to such 

It ridiculous to assume that there are no devices for which it makes 
sense to only talk with devices on the local network segment. In the 
case of a car, it might be nice if some of the various computers talked 
to each other with ip instead of the proprietary protocols they use. 
I'd really like it if my alpine DVD player had a web browser that could 
bring up a configuration page for some of the options for my car. I 
really don't like having to use pedals, switches, knobs and dials in 
some obscure way to do something as silly as disable the horn when I 
lock the car. In some of the devices in the car, it may not be seen as 
worth while to implement DHCP, how often is DHCP really going to be 
used. The car may have an ethernet jack and I may hook it up to my home 
network sometime so I can copy some music from my computer to the sound 
system in the car. When I hook the car up to my home network, a DHCP 
server will be present. I'd still like my computer with a global 
address to be able to communicate with devices in the car that have LL 
addresses.

This whole thread has gone pretty far off track. The suggestion was 
made that there be a way to disable IPv4LL. It hasn't yet been made 
clear if that means disabling the ability of nodes to acquire IPv4LL 
addresses or the ability for any device to communicate with a device 
that has only an IPv4LL address. A DHCP option was suggested, along 
with a new as yet undefined protocol, the strawman one.

If the draft is changed to suggest that a device only acquire an IPv4LL 
on an interface that does not have a global address, then the DHCP 
option for disabling IPv4LL doesn't make a lot of sense.

Enough about MIT already. There's nothing to stop people from running 
AppleTalk or IPv6 on their wireless network for sharing files or 
printing. There is no protocol defined to disable AppleTalk. There is 
no protocol defined to disable IPv6. Similarly, there is no protocol to 
disable manual configuration of IPv4 addresses or DHCP. I still don't 
see why we should define a protocol to disable IPv4LL.

I think it makes sense to only acquire an IPv4LL address when the 
preferred configuration method fails (dhcp, bootp, whatever). I think 
it makes sense to allow hosts with global addresses to communicate with 
IPv4LLs. I think some devices may choose not to implement DHCP and rely 
on IPv4LL for their addresses. I don't believe we should explicit 
restrict the possibility of such devices.

-josh

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 19:04:16 -0500

> > Whether LL is appropriate depends on the needs of the user, the needs of
> > the application, and the policies of the network on which it would be
> > used.  It has nothing to do with what you want.
> 

Nope.  I'm saying, if DHCP exists, let DHCP dictate whether LL is used.  DHCP
can say yes, DHCP can say no.  I don't even care much whether the default
is yes or no as long as hosts that support LL are expected (in the absence of
explicit configuration) to try a DHCP query and if it responds, honor what it
says.

Or if DHCP is too onerous, require LL hosts to support at least bootp.  Or if
that is too onerous, require that LL-capable hosts recognize some specialized 
response to claims for LL addresses that means "this network does not use
LL, use this address/netmask/default instead".  The amount of extra code
required to support this can be made very small.  But there needs to be some
way for a managed network to disable LL.

> It's not for you to decide that either.

Hey, I'm not the one who is insisting on changing the behavior of existing
widely-used interfaces.

> > circumstances.   But multiple global addresses cause few problems because
> > the app generally works no matter which address is chosen.  OTOH, scoped
> > addresses cause lots of problems.
> 
> for you. 

I have no trouble sorting it out.  Very few IPv4 hosts have multiple addresses
on even a single interface, and the few that do have multiple addresses tend
to be used for a few specific apps that are built to deal with that.

> And multiple addresses of different scopes don't have problems

Again, you don't get to impose your idea of the role of the OS (and what it
means to circumvent it) on application writers.

> > inherently untrustworthy and open to abuse.  (of course, you want to
> > define what trust and abuse mean for other people's networks.)
> 
> No, *you* want to torpedo LL.

No, I want to fix it.  You are the one who keeps insisting that LL be imposed
on everyone rather than made available to those networks that want to use it. 

> I think that it's a noble, and good idea. But
> random future. 

You contradict yourself.  LL makes networking harder, not easier.

Keith

---

From: "Bill Rees" <[email-masked]>
Date: Mon, 20 Jan 2003 16:16:02 -0800

----- Original Message -----
> You contradict yourself.  LL makes networking harder, not easier.

Seems to me that LL makes networking easier for the end user/device which is
the apparent goal of zeroconf.  The fact that life may be more difficult for
network admins and it folks or even us is secondary.

---

From: "s. goswami" <[email-masked]>
Date: Mon, 20 Jan 2003 19:28:05 -0500 (EST)

> explicit configuration) to try a DHCP query and if it responds, honor what it

Here is the implict assumption that all LL hosts has a DHCP
client.

> way for a managed network to disable LL.

disable at the client LL host (to the managed network ) ? The
infrastructure  should broadcast messages saying it is capable of doing
LL, the LL hosts can listen for these messages and then configure
a random LL address.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 19:31:23 -0500

On Mon, 20 Jan 2003 15:38:08 -0800
Joshua Graessley <[email-masked]> wrote:

> >> What's wrong, is that limits the ability to develop a class of 
> >> devices that ONLY operates in the linklocal addressing block. There is a
> >great > deal of interest in such devices, and, IMO, no good reason to
> >preclude such > from the market.
> >
> > this is not in the group's charter. and it's ridiculous to assume that 
> > any device only needs to talk to other devices on its local network 
> > segment. it's even more ridiculous to demand that every IPv4 host that
> > wants to support zeroconf be configured by default to be able to talk to
> > such dysfunctional devices.
> 
> sense to only talk with devices on the local network segment. 

Nobody is making that assumption.  

The assumption is that 
a) there are few devices for which it really makes sense to restrict them to
talking only on the local network segment,  (so few that it's not worth it to
have a special facility for them)
b) most devices built with such restrictions would be making unwarranted and
unreasonable assumptions about the organization of their users' networks
and/or the relative properties of on-link vs. off-link hosts
c) such devices would, if widely deployed, constrain the organization of
networks in an unproductive way, e.g. encouraging more use of bridging when
routing might be more appropriate, or vice versa, when other means of access
control would be better and more flexible
d) scoped addresses mess up the IP architecture, and increase the burden on
applications that need to use them, so it's wise to avoid them as much as
possible

> In the 

Fine; just don't expect IETF to say that it's acceptable for car devices to
speak only LL.   I want my car mp3 player to be able to sync up with my home
mp3 collection over an 802.11 network when it's parked in my driveway, or over
a cell phone when I'm on the road -- and my house and my car are unlikely to
be on the same network segment.  

(For that matter, don't assume that the devices in the car are going to be
clients and that they'll initiate all connections - I want to be able to push
new tunes to its mp3 player from my warm cozy house.  My car needs a global IP
address, which given the address shortage in IPv4 implies IPv6.)

> In some of the devices in the car, it may not be seen as 
> used.

So pick a simpler mechanism to allow the devices to determine whether they
should be assigned an address or they should pick one.  But don't impose the
architectural restriction that all of the hosts on an automotive network have
to use scoped addresses.

> The car may have an ethernet jack and I may hook it up to my home 

I have no problem with that.  What I have a problem with is:

a) IETF saying that any device that supports LL should always support LL,
without giving the network any mechanism to disable it.  (the mechanism
doesn't have to be the mere presence of a DHCP server, but there does need to
be a mechanism), or 
b) IETF saying that it's useful for a device to support only LL

> preferred configuration method fails (dhcp, bootp, whatever). 

agreed.

> I think it makes sense to allow hosts with global addresses to communicate
> with IPv4LLs. 

agreed, provided v4LL is permitted on that network segment.

> I think some devices may choose not to implement DHCP and rely 

I don't think it's reasonable for devices to assume that v4LL only is
sufficient.  DHCP might be too onerous, if so we need another mechanism.  
Trying to forbid such devices might be going too far, but we should probably
try to strongly discourage folks from producing such things.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 19:34:45 -0500

On Mon, 20 Jan 2003 16:16:02 -0800

> network admins and it folks or even us is secondary.

in the end, LL makes networking more difficult for everyone.    instead of
configuring hosts and networks you end up configuring apps that need to try to
circumvent the limitations imposed by scoped addresses.

minimizing IP configuration is a noble goal - and LL is a step backward.

---

From: "Bill Rees" <[email-masked]>
Date: Mon, 20 Jan 2003 16:44:37 -0800

> try to strongly discourage folks from producing such things.

There will certainly be deivces that support only v4LL and to suggest that
vendors include extra cruft to handle multiple configuration protocols is
probably futile.  I don't know yet, but will definitely check, whether the
devices Apple and their partners have produced according to the Rendezvous
spec are v4LL only devices.  To discourage this practice is naive at best
and just as arrogant as the notion that IETF will dictate how to configure
networks.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 19:48:12 -0500

> and just as arrogant as the notion that IETF will dictate how to configure

It may be naive to assume that people won't try to do harmful things. But that
doesn't mean that IETF should endorse people doing harmful things, and there
are good reasons for IETF to say that those things are harmful even if it
won't prevent vendors from doing them.

Keith

---

From: "Bill Rees" <[email-masked]>
Date: Mon, 20 Jan 2003 16:57:18 -0800

----- Original Message -----
> minimizing IP configuration is a noble goal - and LL is a step backward.

No.  LL is a definite step forward simply because no steps have happenned to
this point.  LL solves a problem in home networks where people have no clue
how to manage a network so if they purchase a new receiver or tv and want
the device to work with the other devices in their living room, it will.  No
DHCP, no bootp, no server.  Any other network environment where more
sophisticated management requirements exist there will surely be mechanisms
to bottle up v4LL especially if you dictate some on/off switch mechanism.

This requirement would be no worse/better than many other instances where
new technology produced unexpected and bad side-effects.  I'm not advocating
casting a blind eye to these problems but I am advocating that to the extent
a fix breaks the goal of zero configuration (think of this as the Rabid
Rights problem with logic) the problem should go into the possibly won't fix
column.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 22:58:58 -0500

> to bottle up v4LL especially if you dictate some on/off switch mechanism.

LL produces a dysfunctional network that can run only a limited subset of the
applications that the Internet can support.  If this becomes the model for
home networks it will cripple home networks.  And as I said earlier, LL
doesn't produce a zero configuration network, it just means that you end up
spending much more effort configuring applications than you would have spent
configuring the network in the current world, and you still get a less
functional network as a result.

LL can be justified for isolated ad hoc networks.  For home networks - or any
connected network - it is a disaster.

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 20 Jan 2003 23:00:43 -0500

> explicit configuration) to try a DHCP query and if it responds, honor what it

Which means that any DHCP server, or any machine acting as one can now blow
away your LL settings, and you'll never know why. Very secure.

> way for a managed network to disable LL.

So, you are saying that it's not okay to have LL packets eating bandwidth,
but it *is* okay to constantly broadcast LL shutoff packets?

> Hey, I'm not the one who is insisting on changing the behavior of existing

LL's not new, neither is multiple addresses on an interface.

> to be used for a few specific apps that are built to deal with that.

And they break nothing on other machines. Thanks for making my point that
multiple addresses on a single interface are not inherently dangerous as you
have suggested.

> means to circumvent it) on application writers.

But you do? If I'm using an application that is ignoring OS services to try
and get IP addresses on it's own, it's a badly written application. That's
what the OS is there for, to do the monkey work. You need to communicate
with another device, you need access to network services, the OS provides
them. That way, you don't have to write your own network stack for every
hardware / os config your application will encounter. It's been quite the
rage for a while now.

> on everyone rather than made available to those networks that want to use it.

But you seem to think that all networks are monolithic entities, and the
reality is, they aren't, they aren't even close, they don't work that way.
Not even the military works that way, much less Universities, or
multinational corporations. You cannot say with any certainty that ALL
segments on a network work the same. There's no logical basis for it.

> You contradict yourself.  LL makes networking harder, not easier.

BWAAHAhAhAHAHA....not on the end that counts it doesn't. And you still have
yet to provide definitive proof of it in a well-documented, repeatable,
verifiable format that is an example of a problem that exists *NOW*.

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: Mon, 20 Jan 2003 23:03:39 -0500

> Here is the implict assumption that all LL hosts has a DHCP

Yep...DHCP won't affect me at all, I don't use it. Manual configuration, so
much for DHCP as a LL management tool.

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: Mon, 20 Jan 2003 23:06:03 -0500

> circumvent the limitations imposed by scoped addresses.

Only if the app is bypassing OS services. The app has no business directly
probing at that level. The user/OS sets the IP address, and the app says, "I
need to communicate with X at this address". The OS handles the rest. If the
app is picking the interface, the app is broken.

john

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

---

From: "Bill Rees" <[email-masked]>
Date: Mon, 20 Jan 2003 20:25:35 -0800

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Bill Rees" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, January 20, 2003 7:58 PM
Subject: Re: Turning off link-locals?

> functional network as a result.

Rendezvous is your worst enemy then.  They will provide a solution to the
home network problem, as will Microsoft and if you want any say in this then
you have to accept LL or something very like it.  The network will not be
dysfunctional nor will limited subset of apps be a problem.  As any new
approach appears, there is always an adoption rate as IPv6 so readily points
out.

If you take the view that LL is more trouble than it's worth, then what
would you do instead?  You could use the 192.168 approach but then you have
the same problem:  small scope, dysfunctional network, limited apps.

If you accept the dysfunctionality as just one state to internet nirvana,
then you can show how to use LL as a simple intermediate step while awaiting
fullscope network configuration.

If LL only provides a means for a sysadmin to make the machine network
visible in some fashion, then you provide enough config that the sysadmin
can remotely config things instead of sitting in everyone's office.  I would
gladly accept this benefit as the only thing LL offers and care less about
any other app.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 23:31:04 -0500

> app is picking the interface, the app is broken.

it's not for you to define what APIs are appropriate for the app to use.

and anyway, the app doesn't have to pick the interface.  scoped addresses break
things all by themselves.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 23:34:38 -0500

> > LL produces a dysfunctional network that can run only a limited subset of
> > the applications that the Internet can support.  If this becomes the model
> > for home networks it will cripple home networks.  And as I said earlier,
> > LL doesn't produce a zero configuration network, it just means that you
> > end up spending much more effort configuring applications than you would
> > have spent configuring the network in the current world, and you still get
> > a less functional network as a result.
> >
> 
> Rendezvous is your worst enemy then. 

rendezvous is a disaster.  shipping it in production code was irresponsible.

> They will provide a solution to the
> dysfunctional nor will limited subset of apps be a problem.  

because you say so?  or because people won't realize that the network used to
be able to support a wider range of apps with less overhead (and more
reliably) before LL screwed it up?

Keith

---

From: "Bill Rees" <[email-masked]>
Date: Mon, 20 Jan 2003 20:49:42 -0800

----- Original Message -----
> reliably) before LL screwed it up?

Because Apple and Microsoft don't give a flying fuck what you think.  They
will provide the apps to use the LL configuration and solve the home
networking market to their benefit.  People won't care that your big
enterprise apps are fucked or that your networks are fucked or that your
pretty theories are fucked.  They only  care about their hegemony and money.

If you cannot present a solution that addresses that problem and provides
the better-ness you desire then get out of the way cause Apple will run you
over.  If, instead, you tag along on their effort, you will much greater
influence in minimizing network problems.  The longer you bash v4LL, the
less influence you will have.

bill

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 00:09:46 -0500

On Tue, 21 Jan 2003 14:46:24 +1000 (EST)
Ian Lister <[email-masked]> wrote:

> >rendezvous is a disaster.
> 
> Oh good, then you'll be able to point to specific things that it has
> broken.

I've already listed several specific problems with LL addressing.
the problems with name lookup are matters for other WGs.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 00:10:57 -0500

> Because Apple and Microsoft don't give a flying fuck what you think. 

maybe not, but I'll do whatever I can to keep them from using IETF to endorse their crap.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 00:27:24 -0500

> it's not for you to define what APIs are appropriate for the app to use.

No, and it's not the programmer's job to ignore OS services, and use
convoluted, braindead methods that are fragile.

> things all by themselves.

No, they can't. They don't DO anything until a service using that address
tries to use it. That's like that silly "TCP/IP isn't chatty"...no, because
with no services running, it's not DOING anything.

Of course, it's also useless without services, but hey, at least it's not
chatty.

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: Tue, 21 Jan 2003 00:28:58 -0500

> rendezvous is a disaster.  shipping it in production code was irresponsible.

Yeah, how DARE apple make computers easier to use...oh wait, that's their
reason for being.

> reliably) before LL screwed it up?

And it'll melt your chocolate, turn your car into a Yugo, and make you watch
"Hello Larry" reruns....

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: Tue, 21 Jan 2003 00:30:13 -0500

> the problems with name lookup are matters for other WGs.

As I recall, you decided not to send those problems to the list, mostly to
spite me. 

So, pardon some of us if we still think you are way out in left field.

john

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

---

From: Alex Karahalios <[email-masked]>
Date: Mon, 20 Jan 2003 22:31:28 -0700

Hi Keith,

I don't think we should discourage anyone from producing devices which 
only speak v4LL. Anyone is free to create devices which speak only 
v4LL, and they are also free to create devices which only speak UDP and 
don't speak TCP. You see, no matter how objectionable you find v4LL and 
no matter what the IETF says, there will always be vendors out there 
that will create their own standards. Apple and Microsoft will head in 
that direction if the IETF does nothing about v4LL or mDNS.

My view on this is more pragmatic. v4LL and the rest of the ZeroConf 
protocols make my life as an embedded network processor vendor allot 
easier. Right now I can have my devices discovered on the network by 
MAC, PC and Linux machines. This a tremendous benefit and the code 
required to do this is rather trivial. There is nothing else out there, 
other than ZeroConf, which covers as many platforms which is ready to 
use.

Alex Karahalios

P.S. I would participate in these discussion more, but I am already 
several months behind in my development work. I was hoping that these 
v4LL issues would have blown over by now. I guess this IETF 
standardization is a slow process. The good news is that nothing has 
changed in the draft in the last 4 months that would require my 
changing any of my code.

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 00:35:08 -0500

> maybe not, but I'll do whatever I can to keep them from using IETF to endorse

It won't matter. Outside of low-level work, like IPv6, the IETF is largely
irrelevant in networking. Oh, they may give an approval to a standard, which
can make it easier to argue for in meetings, but face the facts...if you
need something to get work done, the IETF's opinion on it, is irrelevant.

What I find interesting is how the IEEE can get work done at a far faster
clip than the IETF, and they deal with stuff that is far more complex.

All you are doing is making the IETF as a whole more irrelevant to people
who only care about the network as far as it provides them with services. If
the network doesn't work, they don't quote RFCs...they call the vendor and
say, "Make it better". If the vendor can't, they get a new vendor.

If people like you have their way, the IETF will, in about ten years, have
all the relevance of three blind monks arguing over the conjugation of the
verb, "To Spam" in ancient greek.

john

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

---

From: Ian Lister <[email-masked]>
Date: Tue, 21 Jan 2003 15:42:53 +1000 (EST)

>clip than the IETF, and they deal with stuff that is far more complex.

That is because the IEEE work is done by people representing corporations,
whose interest is in shipping useful product quickly. But that's pretty
off topic :-)

Ian

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 08:37:50 -0500

> don't speak TCP.

and anyone is free to create devices which violate the IP, TCP, or UDP
specifications too - even though this does harm.  NATs are a good example.

but I don't think IETF should recommend practices that are harmful, and I do
think that IETF can provide a valuable service by recommending against
practices that are harmful.  and LL is harmful unless it's used sparingly.

> You see, no matter how objectionable you find v4LL and 
> that will create their own standards.

yes.  but this is an IETF working group, so we're talking about what IETF
should be doing.

> easier.

and if you don't support other means of your devices obtaining an address,
they make your devices a lot less functional.  it would be really unfortunate
if dysfunctional devices became the norm.

Keith

---

From: Brad Davis <[email-masked]>
Date: Tue, 21 Jan 2003 10:27:52 -0700

> whose interest is in shipping useful product quickly. But that's pretty

The IEEE is not fast (see how fast the 802.11b standard worked through committee 
and look at the political battles between the two groups) and the ISO is even 
slower (why don't we have faster fax machines yet?).

The last effort I spent time on was PPP and PPP-ML.  None of that even comes 
close to matching the prototype protocols (and all the companies involved, 
including the company that created the prototype, changed their code a number of 
times).

Brad Davis

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 21 Jan 2003 10:17:35 -0800

> maybe not, but I'll do whatever I can to keep them from using IETF to 

<sarcasm>That's a wonderful idea. That way IPv4LL can go the way of 
NAT.</sarcasm>

IPv4LL does solve a problem, it is useful. It may break a small number 
of applications. Perhaps with work we can document that or reduce the 
number of applications broken. We can also define how IPv4LL should 
work so it will behave consistently across all platforms and products.

NAT is evil and nasty, but it's really useful for tens of thousands of 
people. The IETF didn't take any part in standardizing how a NAT should 
work. The result? No two NATs work the same way. Anyone working on a 
NAT traversal solution has to contend with the slight variations in the 
way that each NAT works. Is this the way things should be? The IETF 
will only bless a standard if everyone comes to a complete agreement 
and there isn't a single person with a loud mouth complaining?

-josh

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 13:40:09 -0500

On Tue, 21 Jan 2003 10:17:35 -0800

> <sarcasm>That's a wonderful idea. That way IPv4LL can go the way of 

sorry, I let my buttons get pushed.

> work so it will behave consistently across all platforms and products.

that sounds good.

> people. The IETF didn't take any part in standardizing how a NAT
> should work. The result? No two NATs work the same way. Anyone working
> on a NAT traversal solution has to contend with the slight variations
> in the way that each NAT works. Is this the way things should be? The
> IETF will only bless a standard if everyone comes to a complete
> agreement and there isn't a single person with a loud mouth
> complaining?

IETF does have a problem in that it has a hard time saying "here's how to do this bad thing, if you're going to insist on doing it, in a way that doesn't cause as many problems as you might otherwise cause".  Though for the case of NAT I don't see how IETF could have helped much.  The reasons we get so many variant behaviors out of NATs is that NATs inherently cause so many problems that fundamentally cannot be fixed.  That doesn't stop NAT vendors from trying to fix them, often in ways that make the problems worse (like having NATs try to recognize addresees that are embedded in packets without specific knowledge of the protocols).

Fortunately, LL doesn't have to be as bad as that.  There's a clear use case for LL in isolated/ad hoc networks, and there are good reasons to provide managed networks with a way of disabling LL.  If we provide for both of these cases then we will have most of the real benefit of LL with the least potential for harm.  With NATs there was not much that could have been done to avoid the harm.

Keith