Subject: 3. Who are we talking about?

From: Stuart Cheshire <[email-masked]>
Date: Thu, 6 Feb 2003 02:28:11 -0800

One mistake I see made repeatedly is being vague about which party we are 
discussing.

Statements like the following are common:

  *You* know if *you* are using NAT. *You* can choose if *you* want to
  use NAT, but *you* have no choice about whether *you* want to use LL.

Who is "you" in this sentence?

There are (at least) three parties who may be involved:

1. The person who owns (or uses, or is responsible for) the computer.
2. The person who owns/manages/maintains the network.
3. The person who wrote the application software.

In the case of a business traveler running Outlook Express on their 
laptop in a hotel room, the application writer has no control over the 
network environment, and neither does the business traveler.

Some people on this list seem to be primarily concerned with the 
environment where (1), (2) and (3) are all the same person.

I think it is a mistake to focus our efforts on this one specialized 
environment.

Most general-purpose application programmers have to try to make software 
that will run in whatever environment the software finds itself in. The 
more predictable the target environment, the easier that it. This is why, 
in many ways, writing PlayStation games is much easier than writing games 
for PCs -- on the PlayStation you know the exact processor speed, amount 
of RAM, screen resolution, etc. The knowledge of the unvarying execution 
environment makes the application programming easier. The more 
user-controlled customization and configuration options we provide, the 
harder we make it for application programmers to produce quality software 
that will work reliably in all possible environments.

To relate this to Zeroconf:

There have been suggestions to make the DHCP server (or similar) control 
whether v4LL is active or not. This assumes that the desires of the DHCP 
server operator are in alignment with the desires of the computer user. 
If they are not, then it assumes that the person running the DHCP server 
has the right and the authority to overrule the computer user. In many 
cases, it is not clear that the person running the DHCP server does have 
this right. For example, does the person running the rogue DHCP server on 
his laptop at an IETF meeting have the right and the authority to shut 
down communication on other computers? Specifically, do they have the 
right and the authority to shut down communication on the computers being 
used by the people running the IETF meeting network, who are trying to 
fix the problem?

Another suggestion was a manual control to enable/disable v4LL. This is 
better, but still has problems. Who controls that manual setting? The 
computer user? The network operator (by coercing the computer user in 
some way)? The application writer (by putting instructions in the 
manual)? What if one application manual says "You MUST turn on v4LL to 
use this application" and another says "You MUST turn off v4LL to use 
this application"? What is the poor user supposed to do? If v4LL is 
always on, and all applications work correctly with it, then it may be 
more work for some of the application writers, but it's much easier for 
the user. Which is more important, ease for the application writer or 
ease for the user?

Answers that seem obvious when (1), (2) and (3) are all the same person 
often don't work when (1), (2) and (3) may not be the same person, and 
indeed when (1), (2) and (3) may not even be cooperating with each other.

The people who own their laptops want to be in control.

The people who operate the network want to be in control.

The people who own write the applications want to be in control.

When those three people want different things, you can't please all of 
them.

A common (and unfortunate) attitude among many IETF participants is that 
the network operator is god, and everyone else is subservient to their 
wishes. I do not accept that this attitude is universally correct. In 
many cases, the network should be there to serve the needs of the users, 
not the desires of the network operator. However, in cases where the 
network operator does have the right and the authority to restrict what 
the users can do, that authority should be enforced at the appropriate 
level, which in my opinion is 802.1X per-port physical access control, 
not IP-level controls which do nothing to control use of the physical 
link via other protocols like AppleTalk, IPX, NetBEUI, etc.

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 06 Feb 2003 19:51:36 +0700

Date:        Thu, 6 Feb 2003 02:28:11 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | Some people on this list seem to be primarily concerned with the 
  | environment where (1), (2) and (3) are all the same person.

Really?   I haven't detected that from anyone at all.   But...

  | I think it is a mistake to focus our efforts on this one specialized 
  | environment.

It certainly would be, if anyone was doing that.   But not even the
people I most disagree with seem to be doing that.   And you know I'm
not, because some of my arguments have been aimed at having the network
manager be able to override what the software author (and perhaps the
user) would like to do...

  | Most general-purpose application programmers have to try to make software 
  | that will run in whatever environment the software finds itself in.

Yes.

  | The more predictable the target environment, the easier that it.

yes, but do remember your engineering philosophy - the programmer is
supposed to be doing more work to make it easier for the user.

  | The more 
  | user-controlled customization and configuration options we provide, the 
  | harder we make it for application programmers to produce quality software 
  | that will work reliably in all possible environments.

Yes, it is harder.   But without (some) configuration options, we make
it impossible instead.   That is, we don't get to control the environment
by assuming one nice (for us) case where everything just works, which means
that the end user is screwed when he happens to end up in an environment which
is different from the one we're pretending exists.   Refer back to your ...

  | There have been suggestions to make the DHCP server (or similar) control 
  | whether v4LL is active or not. This assumes that the desires of the DHCP 
  | server operator are in alignment with the desires of the computer user.

No.   It most certainly does not.   It assumes that the DHCP server operator
is the one in charge, and gets to dictate to the user.

  | If they are not, then it assumes that the person running the DHCP server 
  | has the right and the authority to overrule the computer user.

Yes.   That's inherent in the design of DHCP (and given that it is in use).

  | In many cases, it is not clear that the person running the DHCP server
  | does have this right.

That's true too.

  | For example, does the person running the rogue DHCP server on 
  | his laptop at an IETF meeting have the right and the authority to shut 
  | down communication on other computers?

Of course not.   They also don't have the right to prevent others from
obtaining a properly routable address.   Saying to an IETF attendee
"here, you can have this bogus address, which won't work" would not
be nice at all.   Allowing the IETF attendee to also get a LL address,
which is useless to 99% of them (who just want to get home and read their
mail, and aren't in the slightest interested in exchanging files with
anyone) doesn't help.   Whether they're turned off completely, or just
made useless, makes no difference.    Just the same applies to people who
make themselves appear to be access points, and screw up the wireless LAN.
Are you proposing a magic solution for that as well?

Where (as is almost always the case, from my experience anyway) this has
happened it is because of an accident, then the right solution would be to
make it much harder for accidents to happen like this - that is, for the
software engineers who implement this stuff to do more work ...

Where someone is deliberately being malicious, this particular method of
attack is the very last one I'd be worried about, attackers connected to
the net have much more potent weapons, readily available.

Also note that the "disable all addresses" option that has been proposed
is effective only when *all* DHCP servers that are available send it.
If a single one does not, then the node will be able to acquire an address
(DHCP always allows the client to select which of the offers it prefers).

So, for this particular issue anyway, some stray user at an IETF meeting
sending out "unlink yourself from the network" is not going to work, unless
they can also manage to prevent the real DHCP server from replying.

  | Specifically, do they have the 
  | right and the authority to shut down communication on the computers being 
  | used by the people running the IETF meeting network, who are trying to 
  | fix the problem?

Of course not.   But no-one is suggesting that manual overrides should not
win in any of these debates.   That is, if the user says "use this address"
or even "Go run the LL algorithm and configure an address" then that's what
the node does, regardless of what any DHCP server might happen to say.

What's more, if in that situation, the "people" were stupid enough to
(attempt to) configure themselves LL addresses to try and diagnose the
problem, then I'd be seriously questioning their competence to be running
any network, let alone one as stressful as an IETF meeting.

  | Another suggestion was a manual control to enable/disable v4LL. This is 
  | better, but still has problems. Who controls that manual setting? The 
  | computer user?

Of course.   Otherwise it wouldn't be a manual setting.

  | The network operator (by coercing the computer user in some way)?

That too, if it works, but that's the computer user again, the only
difference is the rationale for their actions.  Specifying that is
way out of our charter.

  | The application writer (by putting instructions in the manual)?

I would certainly hope not - as, as above, the application writer has
no idea of the environment in which the software will be used - their
job is to make it work, whatever the environment, whenever it is
possible.

  | What if one application manual says "You MUST turn on v4LL to 
  | use this application" and another says "You MUST turn off v4LL to use 
  | this application"? What is the poor user supposed to do?

Throw out both pieces of software, and get some that functions.
(Of course, this is a very contrived example anyway, it is hard to
conceive of anything which would actually care what kind of address
the node has, as long as it has one - whether the address the node
has is going to be successful to reach a peer is something that the
software can only ever tell by trying it - then if it fails, all the
software can do is report that, we don't currently have any method
of somehow guessing what address would have worked to reach that other
guy who simply didn't answer).

  | If v4LL is always on, and all applications work correctly with it,

That's an assumption.   Not that the application writers would have to
do more work, but that it is actually possible to do the work.   If it
turns out to be impossible, what then?

  | Which is more important, ease for the application writer or 
  | ease for the user?

Ease for the user of course - but that doesn't mean "LL is always on"
is the answer, it means "application writers must write code that works
with or without LL addresses".

  | The people who own their laptops want to be in control.

Of course they do, and they can be, as much as they're able - and
of course, assuming they're aware that when they start dictating how
things should be, they have to be responsible when that causes things
to fail.

  | The people who operate the network want to be in control.

Of course, it is their network, they are in control.

  | The people who own write the applications want to be in control.

They shouldn't.   Remember the engineering principles - they're supposed
to do more work ...

  | A common (and unfortunate) attitude among many IETF participants is that 
  | the network operator is god, and everyone else is subservient to their 
  | wishes.

The problem is that this all depends upon the level at which you look at
this.

  | I do not accept that this attitude is universally correct. In 
  | many cases, the network should be there to serve the needs of the users,

Of course it should.   And it is the network operator's job to make it so
(in those cases - there are others where the network is not intended to
serve any needs of random users at all.)

  | not the desires of the network operator.

A common problem here seems to be the assumption that the network operator
is some evil bastard deliberately attempting to make life difficult for the
users.   That's not how it is (usually - and where it is, that network
operator should be sent to some more appropriate occupation).

Where problems arise is when the network operator is attempting to serve
the needs of all the users, rather than one in particular, and that one
believes that their needs should be supreme to all others, which is a
very common scenario.   Just because the user doesn't understand the
reasons for what the network operator is doing (which may mean that better
communication is needed) or simply doesn't like it because it interferes,
doesn't mean that the user should be blindly overriding things (even
if we're not about to say here that they can't).   It most certainly doesn't
mean that the user's system should be blindly overriding the network
operator, without even asking the user's consent, on the assumption that
"of course this way will be better".

  | However, in cases where the 
  | network operator does have the right and the authority to restrict what 
  | the users can do, that authority should be enforced at the appropriate 
  | level, which in my opinion is 802.1X per-port physical access control,

Sometimes that's entirely appropriate.   But it certainly isn't always.
Most times the network operator isn't trying to lock the user out (which
is what this would be doing, it is a pretty blunt instrument) but to
assist the user interoperate correctly with all the other users of the
network.   The network operator tends to be the one with the information
required to make that happen.   Users should have very good reasons before
deciding to override that (and then should be prepared to have 802.1X
type controls applied to them when it turns out they're wrong).

kre