Subject: 2. Disabling LL -- or -- How does a host know if it is configured correctly?

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

Christian Huitema wrote:

>What would be wrong would be to force systems that already have
>a DHCP address to also acquire a more ambiguous, scoped address.

Keith Moore wrote:

>there is no situation where you need both v4LL and a
>routable address on the same interface.

One of the goals I believe is important is creating reliable networking 
that doesn't fail.

Just having a configured routable address doesn't mean that it is 
necessarily correct or currently usable.

Windows machines have a tendency to cling to their DHCP leases until they 
expire, even though sleep and restarts. If you and I meet while waiting 
for a flight at an airport and want to exchange files, it is entirely 
possible that my laptop still has an unexpired lease from my network, and 
your laptop still has an unexpired lease from your network. If we connect 
the two laptops with an Ethernet cable, they cannot communicate using 
those addresses. The addresses and subnet masks are are incompatible. The 
configured router addresses are unreachable.

If our laptops were to configure IPv4LL addresses in this situation, 
despite having configured routable addresses, then that would enable 
smart application software to try both, and find that even though the 
configured routable address does not work, the IPv4LL address does, and 
that allows the users to exchange their files.

Allowing the users to succeed where otherwise they would have failed 
seems like a good thing.

Too many networking geeks confuse understanding a problem with solving 
it. In the situation above, the friendly networking geek might run a 
packet sniffer, work out what was wrong, and chuckle and explain 
condescendingly to the poor computer users how it was their fault for 
failing to remember to manually release their DHCP leases! What's wrong 
with this is that diagnosing a problem is not the same as solving it. 
Solving it means changing the software so that the problem never happens 
again.

Before anyone rushes to criticize Windows here, there's a good argument 
that the Windows behaviour is correct. We have had many customer reports 
of problems where they have unreliable DHCP servers that keep crashing. 
When this happens, the Windows machines cling to their DHCP leases though 
sleep and restarts and continue to work, whereas the Macs, unable to get 
a response from the DHCP server after a reboot, fall back to a 
self-assigned link-local address. You can lecture these people about 
having reliable DHCP servers that don't keep crashing, but from their 
point of view the Windows machines work and the Macs don't so it's a Mac 
problem.

If the machines were to cling to their old DHCP leases *and* configure a 
self-assigned link-local address, then you'd have the best of both worlds:

* When you don't hear from the DHCP server because it crashed, you
  nevertheless can continue to use your routable address.

* When you don't hear from the DHCP server because you've moved to a
  different network that doesn't have a DHCP server, you have a link-
  local that works for all other compatible hosts on that physical link.

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:01:10 +0700

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

  | One of the goals I believe is important is creating reliable networking 
  | that doesn't fail.

There is no such thing.

  | Just having a configured routable address doesn't mean that it is 
  | necessarily correct or currently usable.

Nor does having a LL address mean that it is usable.

If an address has been configured for a node, and it is a bad address,
then it ought to be fixed (in the same way it was originally configured,
however that was).   That needs to be done anyway.   Papering over the
misconfiguration by making the node seem to work for some things does a
dis-service to everyone in the long run.   At the very least it increases
confusion.   Users might not be very happy when they learn that someone
screwed up their configuration, so they can't use the net - but they also
understand human error, and cope with it (are you also planning to handle the
case where someone screwed up the wiring to the interface cable, in the
cases where there is one?)   On the other hand, allow the user to see that
their system is "working" (see, I can print, access files, ...) but they
can't do everything, and they're going to assume that something else is
broken instead, and often refuse to believe that their system has any kind
of problem at all "it works, I proved it".

  | Windows machines have a tendency to cling to their DHCP leases until they 
  | expire, even though sleep and restarts. If you and I meet while waiting 
  | for a flight at an airport and want to exchange files, it is entirely 
  | possible that my laptop still has an unexpired lease from my network, and 
  | your laptop still has an unexpired lease from your network. If we connect 
  | the two laptops with an Ethernet cable, they cannot communicate using 
  | those addresses. The addresses and subnet masks are are incompatible. The 
  | configured router addresses are unreachable.

That's a bug.   I'll come to why in a minute.

  | Too many networking geeks confuse understanding a problem with solving 
  | it. In the situation above, the friendly networking geek might run a 
  | packet sniffer, work out what was wrong, and chuckle and explain 
  | condescendingly to the poor computer users how it was their fault for 
  | failing to remember to manually release their DHCP leases!

I suppose a "geek" might just do that.   Someone who really understands would
explain that the software that acted this way is broken, and should be
returned for repair...   Just the same as if the problem turned out to be
a broken wireless card that wasn't actually transmitting.

  | Before anyone rushes to criticize Windows here, there's a good argument 
  | that the Windows behaviour is correct.

No there isn't.

  | We have had many customer reports 
  | of problems where they have unreliable DHCP servers that keep crashing. 
  | When this happens, the Windows machines cling to their DHCP leases though 
  | sleep and restarts and continue to work,

As they should.   But that isn't the situation you described above.
Here, the system is still on the link where the address works.   Above
it wasn't.   When no DHCP server responds, the client should examine
its existing leases, see if any remain valid (have not expired - and note
that there might be many of those, not just one) and then attempt to see if
one of those still appears to work.   The easy way to do that is to see if
any of the addresses that the previous lease contained respond to ping
(the default router, the time server, ...)   If none answer, then there's
a very good chance that what has happened is that the node has moved to
a new net with no DHCP, and its leases should all be ignored.   That's your
airport example - so you just configure your LL address and continue.
On the other hand, if the DHCP server has just crashed (a phenomenon which
happens much less frequently these days than it used to) it is very unlikely
that the router, NTP server, printer server (anything else that was in the
DHCP response from before) have also all crashed.

  | whereas the Macs, unable to get 
  | a response from the DHCP server after a reboot, fall back to a 
  | self-assigned link-local address.

That's also broken.   If it has a lease which is still valid, and which
still works, it should go ahead and use the thing.

  | You can lecture these people about 
  | having reliable DHCP servers that don't keep crashing, but from their 
  | point of view the Windows machines work and the Macs don't so it's a Mac 
  | problem.

And if you observe the DHCP mailing lists, you'll see frequent cursing of
Windows systems for just this behaviour (though much of it probably relates
to earlier, even more broken, behaviour).

They're both wrong.

Please refer back to your Engineering philosophy - the software engineers
should be doing more work in order for the users to have to do less, and
for things to break less often.

In this case, assuming what you say is correct (I use neither Windows nor
Apple stuff), then the software engineers simply haven't done enough work
in either of those systems yet.

kre