Subject: 1. Engineering philosophy

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

I have observed two attitudes towards engineering:

Attitude 1. The engineers creating the products should be willing to do a 
lot of hard work to make the lives of the end users easier, more 
pleasant, and more productive.

Attitude 2. The customers buying the products should be willing to do 
work to make the lives of the engineers easier.

I make no apology for following principle number 1, and that attitude is 
common at Apple.

Some people follow principle number 2. They believe that when there is an 
unavoidable decision to be made between (a) extra work for the 
application programmers creating the products, or (b) extra work for the 
people using the products, the correct answer is that the end-users 
should suffer to make life easier for the application programmers.

Such people are entitled to hold their views, but they won't persuade 
Apple to produce its products according to that principle.

My sincere goal is to have as little impact as possible on application 
software, but when we do arrive at an unavoidable engineering trade-off 
between making life easier for the end-users or making life easier for 
application programmers, we have to decide what our priorities are.

I will state my position very clearly: As an engineer and programmer, I 
am willing to work hard to make life easier for end-users, and I think I 
am justified to take pride in the software and hardware I have produced 
by following that philosophy.

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

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 7 Feb 2003 10:34:41 -0000

> From: "Stuart Cheshire"

Darn right they should.

My conclusion is that we - as a group of engineers - have not done enough
hard work. The evidence is that we are unable to agree what the zeroconf
draft should say after lengthy debate which swings from side to side but
rarely if ever forward. I certainly don't see many people here suggesting
that end users should make engineers lives easier - what I do see is a lot
of differing views of who the end users are and how they are best serrved.

My experience as an engineer confronted with this sort of situation is
generally that you need to stand back and question whether you are solving
the right problem - or whether it needs solving at all. We have beaten this
particular draft to within an inch of its life and if it eventually gets
through it will as likely be from exhaustion and disenchantment as from real
engineering agreement.

The zeroconf WG seems to have a bad charter. Nearly all the sticking points
are to do with how v4LL scales from the single link network to larger ones
which means interaction with DHCP (on larger networks DHCP effectively
zeroconfig networking from the users viewpoint). This highlights the fact
that v4LL does not exist in isolation - oh for that luxury! I think we
should look outside the current LL draft at the bigger picture. If this
means revising the WG charter or making it part of the DHCP group or
something then so be it - that is in the ultimate interests of the user.

My belief is that what most people here recognise that the problem of how to
get an IP address on a single link unmanaged network is not an isolated case
but is one extreme of a space which extends through home networks with NAT
right upto large complex heavily managed networks and also includes networks
of embedded systems where user interfaces are few, far between and extremely
restricted.

On the one hand we have the "restrict LL" people who (rightly) point out
that allowing v4LL to operate unrestricted on routed networks causes all
sorts of trouble. On the other hand we have the "LL for all" people who
(rightly) point out that waiting minutes for your system to go through some
lengthy and unreliable configuration and checking process before finally
reluctantly falling back to a LL only address is unacceptable.

So I suggest that the "restrict LL" camp look at how they can address the
problems of unreliability and unacceptable configuration time, while the "LL
for all" camp look at how they can answer the issues of broken applications
and lack of proper functionality as the network scales. Simply denying the
problems isn't going to work and it is pretty obvious that no simple
definition of when to turn LL on or off is going to either without some
change in other areas.

Do a bit more hard work instead of bickering over the work that has been
done already which obviously doesn't cut it!

Philip

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 07 Feb 2003 10:21:53 -0500

> of embedded systems where user interfaces are few, far between and extremely

I don't think you can solve this problem in a way that makes everyone happy,
and maybe we shouldn't try. But what we can do is make incorporating some
standard form of IP in any device that talks to another device without
requiring a third party configuration server dead simple.

You cannot do this with DHCP. We can argue until the cows come home, but
there is only one way to *guarantee* the presence of a DHCP server and that
is to have *everything* be a DHCP server. Since DHCP turns into a stinking
mess when this happens, especially when you have dozens of DHCP servers
coming up and down, this will never be a good solution.

As well, regardless of personal feelings towards NAT, it is here, and it is
widespread, and we have to deal with this as well. We don't have to make it
work, we just have to acknowledge that any standard we define will, not may,
but *WILL* be used in a NAT environment. It is far better to deal with this
as adults, rather than "I don't like it so I'm not dealing with it" manner.

Finally, we need to make this easy to use. Yes I know, a good percentage of
the people on this list are still angry about common folk on the Public
internet. Oh well, they pay the bills.

We cannot require that every single device using IP have a permanent global
address. There are emotional reasons, and monetary reasons this won't
happen. Under IPv4, there are numerical reasons this simply cannot happen.

So we're kind of stuck with IPv4LL. Now, some would like to guarantee this
WG accomplishes nothing until IPv6 makes this all moot. But the world has
work to do that cannot wait the 4-7 years it will require for this to
happen. 

So now, we have to deal with how to avoid harm. How not to break what is
there. First, we cannot completely avoid harm. All changes break stuff. So
at best we minimize it.

I'm not going to address the security boogeyman, I have yet to see
verifiable, repeatable evidence that v4LL introduces any threats that aren't
there now. A properly run and secured network will have people who deal with
this, one that isn't won't, and no amount of standard verbiage will
compensate for the latter.

So when to use v4LL? It's pretty obvious that you want to use it in cases
where you don't have any other sort of managed network. That's obvious.

But what about managed networks? There's some complications either way.

If you use DHCP, then implementation details *are required*. You cannot
simply say , "DHCP disables v4LL". That's dumb, and any third year EE
student will show you why.

If you have a manually set address, then automatically disabling v4LL is
even dumber, because now you will be unable to join an ad hoc network
without reconfiguring your machine to use DHCP, and hoping that there isn't
a DHCP server nearby, wired or otherwise.

So the other option is to leave v4LL active all the time. There are of
course problems with this as well, but not as many as people think, or try
to make it out to be. First of all, multiple addresses per interface are a
no-brainer. Been done for years, everyone knows how to deal with this. That
by itself is not a major issue.

So the problem then is what do you do with an address that is far more
limited in scope than a 'standard' address. That is going to be the problem
to solve right there. So now, from the people on the list who do IP stack
implementation and programming, how would you go about solving that problem?
(I'm limiting this to them, because they have far more of a clue than the
rest of us who never have, or no longer do that sort of work.

Now, the next issue this raises is how to keep v4LL traffic off your network
when you don't want it there. I'm going to agree with Keith here and say
that there are times when you need to be able to control a network at that
level. However, this problem is not universal. If you have a switch that can
filter traffic, then you simply block v4LL on your network, and you're done.
Wireless can be a little harder here, but again, a firmware update can add
that capability to a wireless router, and if a given vendor can't or won't
offer that capability, then the market will deal with them appropriately,
(via Adam Smith's lesser well known invisible middle finger.)

*BUT* you do have the issue of k-12 schools, small businesses, etc using
older equipment that doesn't have this feature, and may never have this
feature, and they can't upgrade anytime soon due to budget issues. (If you
don't believe me, check out Massachusetts budget cuts these days...k-12
ain't got money for squat!) So, switch blocking isn't an option. But, there
is a way to do this, and that's with a manual setting.

Yes, I know it's tasteless, but it's needed. Now, I don't mean manual as in
'requires physical contact with the keyboard'. I mean manual in the sense
that ifconfig settings, top, kill, ping, etc. are manual. This switch would
have to be set by default to allow v4LL. It doesn't have to be even an
traditional switch. For example, on Mac OS X 10.2, the switch could be *not*
setting a Rendezvous name, or better yet, a config option in Directory
Services. Even better, a switch to ifconfig.

But there is another problem, and that is laptops. Desktops are easy, they
don't move much. Laptops are another issue. So, you treat them different,
and you put the v4LL switch in an obvious place in the UI. (Before anyone
starts about onerous requirements to the vendor, they have special UI
features for laptops NOW...oddly enough my tower doesn't seem to have a way
to configure power consumption on battery power.)

Stuart's right about one thing, v4LL has to be easily available. Keith's
right about one thing, there has to be a way to turn it off when needed. You
cannot rely on an automatic network configuration method, because manual
addressing will blow it all to hell. As well, in the case of a rogue DHCP
server, you need a way to override the DHCP cutoff for v4LL.

I'll bet a bottle of Guiness right now that even if you manage to force the
issue of automatic restriction *only* for v4LL, it will be either so roundly
ignored, or a manual setting will be included *anyway*, because it's needed,
that it will end up being part of the standard.

Oh, on the issue of accidentally routing v4LL addresses...Cisco and the rest
can handle that with a firmware update, so that's not a big deal at all.

john

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 7 Feb 2003 10:48:10 -0500

John,

Face it, v4LL is dysfunctional.  It's better than nothing for ad hoc,
disconnected networks.  But the cases where it will work better on 
connected networks are so marginal that the complexity that results with
trying to deal with a mixture of v4LL and routable addresses is simply
not worth the gain.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 07 Feb 2003 11:31:58 -0500

> trying to deal with a mixture of v4LL and routable addresses is simply

I disagree...it's been here for years, and with things like bluetooth
creating things that won't need or want a global address, there's a need to
make it work correctly with larger networks.

john

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

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 7 Feb 2003 16:58:20 -0000

> From: "John C. Welch" <[email-masked]>
>
> > disconnected networks...
> I disagree...  ...there's a need to

Will you two just stop it! You are both right - how can you disagree?

You both agree that v4LL fulfills some need and you both agree that it has
problems and seem to recognise what they are even if you give them differing
relative importance. So go and work out how to fix them then come back and
tell us all about it.

Philip

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 7 Feb 2003 17:52:10 -0000

> From: "Keith Moore" <[email-masked]>
>
> that's just the point - the problems aren't not worth the trouble to
> fix.   or to put it another way, the best fix is to not use v4LL
> whenever you have a routable address that you can use instead.

Sorry - not good enough.

There are genuine problems with knowing whether you have a routable address
which works, or with taking too long to find out, or too long to get it, or
with it being unreliable. Fix these problems and the objections go away. You
hinted at a possible solution when you replied to Bill Rees yesterday. Give
us the detail, not just hints:

Philip

---

From: Keith Moore <[email-masked]>
Date: Fri, 7 Feb 2003 16:14:48 -0500

> There are genuine problems with knowing whether you have a routable
> address which works, or with taking too long to find out, or too long
> to get it, or with it being unreliable. Fix these problems and the
> objections go away. You hinted at a possible solution when you replied
> to Bill Rees yesterday. Give us the detail, not just hints:

1.  v4LL is too dysfunctional to be used as a realistic backup for DHCP
on the vast majority of connected networks.  If DHCP is unreliable, DHCP
needs to be fixed rather than expecting v4LL to solve the problem.  
But fixes to DHCP need to be made by the DHC working group. The most
this WG should do about those is state the problems for which fixes are
needed.  (Note that to the extent these problems exist, they exist
independently of LL.)

2. As for "knowing whether you have a routable address that works": 
If there's a misconfigured DHCP server that's handing out useless
addresses, this is a network configuration problem.   LL-capable hosts
shouldn't be trying to second-guess network configuration even when the
server appears to be misconfigured.  The most they should do is say
"there's a network configuration problem".

3. As for rogue DHCP servers, DHCP authentication is already defined in
RFC 3118, and any LL-capable device is free to implement that.  If
there's some suggestion that this group can make for making it easier to
use RFC 3118, I'm sure the DHC group would love to hear it.

4. As for "too long to get the address", the most that I think this
group should specify regarding interaction of LL and DHCP is this:

a) minimum amount of time a device should wait for a DHCP reply before
starting to configure LL (T1 in the diagram below).
(suggestion: 0-2 seconds)

b) mininum amount of time a device should wait for a DHCP reply before
starting to use the LL address as either a source or destination address
(T2) (suggestion: 5-10 seconds)

c) minimum and maximum intervals to wait before attempting again to get
an address from DHCP after having failed to obtain one (T3, T4)
(suggestion: 5 minutes, 10 minutes)

d) maximum amount of time a device should continue to use the LL address
as a source address for new connections after obtaining an address from
DHCP (T5) (suggestion: a few seconds)

e) maximum amount of time a device should accept new connection attempts
at an LL address after obtaining an address from DHCP (T6) 
(suggestion: 5-10 minutes)

start DHCP     start LL         start using                   start DHCP
discovery      configuration    LL address               discovery again
|             /                 |                                      |
|            /                  |                                      |
|           /                   |                                      |
------------------------------------------------------------------------
+----T1--->|                    |                                      |
+---------------T2------------->|                                      |
+---------------------------T3 + rand(T4-T3)-------------------------->|

notes: T2 > T1, T3 > T2

address obtained          stop using                  stop using
from DHCP                 LL source address       LL destination
|                                |                              |
|                                |                              |
|                                |                              |
-----------------------------------------------------------------
+--------------T5--------------->|                              |
+--------------------------------T6---------------------------->|

notes: T5 could be greater than, less than, or equal to T6.

-----------------------------------------------------------------------

The other idea I keep coming back to is to define some sort of magic
ARP response to an ARP broadcast reply for an LL address to mean "try
using DHCP before configuring LL".  For instance, an ARP reply
associating the LL host's ethernet address with some well-known IP
address (say 127.0.0.255) would be an indication to that host that it
should try to get an address from DHCP and wait at least T2 seconds
after trying before using any LL address.

(So in this scenario, the LL host would "start LL configuration"
first, and if it didn't see any "magic ARP response" or conflict within
the required interval, it would then start using the LL address.  It
should still try DHCP discovery immediately, and again at
irregular but bounded intervals, but it doesn't have to wait T2
seconds before using the LL address - it would be immediately
available.)

The purpose of this is that by giving the network a way to quickly say
"don't use LL", the network can discourage LL without forcing LL-capable
hosts to time out waiting for a DHCP response on networks that don't
have a DHCP server. The worst that would happen is that, on networks
that did support DHCP and did not provide the magic ARP response,
LL-capable hosts would configure an LL address that they would quickly
abandon.

This should be a simple change to LL host code because it would not
require the LL host to recognize a different packet type while waiting
for responses to its ARP broadcast.  All it has to do is look for
responses with the same Ethernet address that it's using in addition
to responses with the same IP address that it's claiming.

Obvious drawbacks: 

a) It can be spoofed.  But the effect of the spoofing is just to delay
use of the LL address by T2 seconds. (Once an LL address is configured,
the host should keep using it until it gets a DHCP address, even if on
subsequent attempts to defend the LL address it gets the magic ARP
message that says "try DHCP first")

b) It requires networks that care to have a couple of servers sitting
around that listen for, and send out, these ARPs.  For convenience in
packaging, this could be an option (disabled by default) in DHCP
servers.  (If you believe that networks won't need to do this, then this
shouldn't bother you much.)

c) I'm not sure it's worth the trouble.  It depends on how important it
is for  LL-capable devices to be able to start working quickly on ad hoc
networks.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 07 Feb 2003 17:11:48 -0500

> needed.  (Note that to the extent these problems exist, they exist

It's not supposed to be a backup in that sense. It's a way to self configure
a local link network address...why would you even consider it as a backup
for DHCP which has a different scope and purpose.

> "there's a network configuration problem".

True

> use RFC 3118, I'm sure the DHC group would love to hear it.

Rogue DHCP servers are the reason for not making DHCP the sole decision for
disabling v4LL on a link. You have older servers, etc.

<some good ideas snipped for brevity>

What do you do about manually configured addresses when the machine 'wakes
up' in a situation where a v4LL ad hoc network needs to be configured?

john

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 7 Feb 2003 17:31:35 -0500

> > 1.  v4LL is too dysfunctional to be used as a realistic backup for
> > DHCP on the vast majority of connected networks.  If DHCP is
> > unreliable, DHCP needs to be fixed rather than expecting v4LL to
> > solve the problem. But fixes to DHCP need to be made by the DHC
> > working group. The most this WG should do about those is state the
> > problems for which fixes are needed.  (Note that to the extent these
> > problems exist, they exist independently of LL.)
> 
> It's not supposed to be a backup in that sense. It's a way to self
> configure a local link network address...why would you even consider
> it as a backup for DHCP which has a different scope and purpose.

People have argued in favor of simultaneous configuration of LL and
routable addresses using the justification that LL will keep working
even if the routable address fails.  This was a response to that
argument.

> > 3. As for rogue DHCP servers, DHCP authentication is already defined
> > in RFC 3118, and any LL-capable device is free to implement that. 
> > If there's some suggestion that this group can make for making it
> > easier to use RFC 3118, I'm sure the DHC group would love to hear
> > it.
> 
> Rogue DHCP servers are the reason for not making DHCP the sole
> decision for disabling v4LL on a link.

No, they are not a justification for that.  v4LL on the link doesn't
solve the problem of rogue DHCP servers.  A host that configures LL on a
link that expects hosts to have routable addresses is still, in most
cases and for most purposes, dysfunctional.

The only way a host can hope to distinguish between a rogue DHCP server
and a legitimate one is to be configured to require authentication.

> What do you do about manually configured addresses when the machine
> 'wakes up' in a situation where a v4LL ad hoc network needs to be
> configured?

The same thing you'd do if you found yourself on a network with a rogue
DHCP server - you manually change the configuration to enable LL. 
Manual configuration does have its problems, one of which is that once
you've explicitly set the network address you can no longer expect the
machine to adapt to changes in network conditions until you turn off
the manual configuration.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 07 Feb 2003 20:53:24 -0500

> even if the routable address fails.  This was a response to that

Ah. Well, in the sense that being able to see something is better than
sitting around waiting for the IS folks to get your network back up, then
yes. But it's better stated as an alternative configuration method than a
backup, which is how I at least, view it.

> and a legitimate one is to be configured to require authentication.

You aren't going to get it, unless you get everyone to update all DHCP
servers to require authentication and all clients to *ignore* DHCP servers
they aren't authenticated for. It's a very good idea, but it's not going to
happen for v4.

> the manual configuration.

But right now, there's no way to override the automatic behavior. Any
attempt to insert that type of behavior has been shot down.

john

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

---

From: Keith Moore <[email-masked]>
Date: Sat, 8 Feb 2003 02:18:53 -0500

> they aren't authenticated for. It's a very good idea, but it's not going to

Note that the threat of a rogue DHCP server is independent of LL.  The fact
that DHCP authentication hasn't become widely deployed may be due to a lack of
good tools to do it (I suspect a uniform means of configuring hosts from an
isolated network connection would help immensely), or a chicken-and-egg
problem (why upgrade servers/hosts if the hosts/servers don't support it?). Or
perhaps it's not (yet) been a significant problem in practice.  Or perhaps the
problem when it does occur is more easily solved by other mechanisms, such as
monitoring and alarms. 

I don't really know the reason DHCP authentication hasn't succeeded yet.  But
I'm quite certain that this WG is not going to produce a better solution for 
making hosts resistant to rogue DHCP servers.

> attempt to insert that type of behavior has been shot down.

Actually I read it completely opposite - I haven't seen any objection to
allowing manual override of automatic behavior.  

If the question of manual override isn't on the issue list, why not ask to
have it added?

Keith

---

From: Erik Guttman <[email-masked]>
Date: Sat, 8 Feb 2003 16:11:37 +0100 (CET)

Keith,

This is a valuable posting.  Thank you, Keith.  Can we reformulate it as
a potential solution to LL2?  Could you post an 'issue' to cover it?

If (a) a host is required to attempt to get configuration (ie. using
DHCP, RARP, manual configuration, whatever) and then (b) to transition
*in an orderly way, as non-disruptively as possible* to using that
configured address, we do not need to specify some additional RFC
2563-like mechanism, right?

(I am eeking to flesh out middle ground between the v4LL-aways and
v4LL-mimosa camps.) 

Erik

> discovery      configuration    LL address               discovery again

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
 E r i k   G u t t m a n                        
 N1 Installation and Provisioning               cell: +49 172 865 5497 
 Sun Microsystems                     pager: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Sat, 8 Feb 2003 11:10:13 -0500

On Sat, 8 Feb 2003 16:11:37 +0100 (CET)

> a potential solution to LL2?  Could you post an 'issue' to cover it?

I think there are probably multiple issues here.  Let me see if I can distill
them out.

> 2563-like mechanism, right?

Maybe not.  At least, I suspect it makes some of the justifications for a 2563
mechanism marginal enough that they're not an immediate concern.

Keith