Subject: On manual control of v4LL

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 11:47:45 -0500

You know, it occurs to me that maybe trying to make the v4LL switch
automatic isn't the way to go.

Think about this, it brings up all kinds of issues, like authentication,
notification, communicating with v4LL without an address, ad nauseum. It's
going to take three pages at least to properly define, and there's going to
be a half - dozen loopholes.

But what if we don't make it automatic in the face of DHCP, or creating some
other protocol to turn it off?

Why NOT make it manual?

It really answers a lot of problems:

1)  Authentication. If you make it a manual process, that needs either
direct human contact to run a command to turn it off, or a script, then you
can use existing authentication mechanisms transparently. SSH, SSL,
Kerberos, etc, blah. We already *know* how to handle manual configs.

2)  Convenience for user and network admin. If your machine is a home
machine, great, v4LL is on, so most home uses are covered, bob's your uncle.
If it's on a network that disallows v4LL, then you turn it off, and it's
off. Not kind of off, not 'only no address off', but off. Zeroconf is less
of a need here, you have ITConf, and you most likely DON'T want users
configuring their machines anyway. Now, how about dual use machines? Well,
Apple at least, and most other OS's have a way to deal with multiple
configurations, so you can have a 'home' and a 'work' setup. 'home' has v4LL
on, 'work' does not.

3)  it makes handling the existence of v4LL programmatically far more
predictable. You can either update code to deal with it, or not. If not, put
in warnings about it, and if people insist on using your app anyway, then
they're being silly. But either way, you have more of a binary issue.

4)  It's a lot simpler to implement. It doesn¹t *have* to have a UI switch.
It could be a standalone app, a new option in ifconfig, whatever.

It avoids rogue DHCP servers from killing v4LL inappropriately. It makes it
easier to keep it off if needed. It provides authentication without adding
in MORE STUFF. It allows home users to not have to worry about cases like
the one Keith ran into. It allows people in environments where v4LL will be
a problem to turn it *off*

It seems to me, that sometimes, manual is the way to go, and this seems to
be a really simple, elegant way to answer all concerns. And it's a quick
read:

All v4LL implementations MUST have a manual way to shut off v4LL. This SHALL
be the only way to turn off v4LL.

I mean...that's 95% of it in two sentences. Not many loopholes.

john

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

---

From: John Schnizlein <[email-masked]>
Date: Wed, 22 Jan 2003 12:02:25 -0500

At 11:47 AM 1/22/2003, John C. Welch wrote:
>...

Why do you think rogue DHCP servers are more of a threat than rogue v4LL hosts?

>be a really simple, elegant way to answer all concerns. 

Is your goal the technology of link-local addresses, or minimizing configuration effort for most users?

>And it's a quick read:

John

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 12:15:04 -0500

> Why do you think rogue DHCP servers are more of a threat than rogue v4LL

Because I work at MIT, and it would be a fun prank to build a little
wireless device whose entire purpose in life would be to broadcast just
enough DHCP packets to kill off v4LL. It's not a real hard thing to do,
building a 'Zeroconf wireless deathtrap'. I used to build IR deathtraps when
I played LaserTag...all you needed was a trainable remote and some duct
tape, and the fun began. I have no faith in humans beyond their amazing
ability to piss on someone else's parade.

There's no easy way to authenticate that a given DHCP server is *allowed* to
kill v4LL. Keith showed a reason why using DHCP can be a bad idea in a
fairly common setup. An additional problem is that under Windows XP, with a
wired and wireless interface, it's a little too easy to accidentally set up
your laptop to be an unauthorized DHCP server. That's not malicious, but it
would effectively kill every v4LL device in range.

Manual only control is convenient, without being onerous. It's a simple
setup, and easy to script. It's harder to accidently use, with proper use of
permissions/ACLs, you can lock it down tight.

> configuration effort for most users?

Both. With Manual config, you ship with v4LL on. So now you have a
consistent shipping config. Easy to plan for. Oh, you don't want your
network to use v4LL. Fine, no problem. It's easily turned off, but not by
'some machine'. Network management tools allow for you to remotely execute
commands on managed machines.

It is a FAR simpler way to please both sides, and isn't as complicated as
the DHCP/BootP proposals I've seen here. It's even automatable, but far more
controllable than other methods.

It *seems* to work really well, which is why I'm a little nervous about
proposing it...it seems too simple...but I can't come up with a reason not
to do it that way.

john

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 13:33:31 -0500

> Think about this, it brings up all kinds of issues, like
> authentication, notification, communicating with v4LL without an
> address, ad nauseum. It's going to take three pages at least to
> properly define, and there's going to be a half - dozen loopholes.
> 
> But what if we don't make it automatic in the face of DHCP, or
> creating some other protocol to turn it off?
> 
> Why NOT make it manual?

<satire>
You know, it occurs to me that maybe trying to make address allocation automatic is not the way to go.

Think about this, it brings up all kinds of issues, like authentication, notification, communicating between ad hoc addresses and managed addresses, ad nauseum.  It's going to take several dozen pages at least to properly define, and there's going to be a dozen loopholes.

Why NOT make it manual?
</satire>

Seems like the very reason we want autoconfiguration is to avoid having to explicitly configure hosts on a per-host basis.  An autoconfiguration solution that optimizes for ad hoc networks and pessimizes for managed networks isn't going to play very well, especially given that the vast majority of existing networks are managed (in the sense that they assign addresses) and the vast majority of deployed applications use hosts from outside the local link.

For an autoconfiguration solution to be significantly more useful than what we have now (i.e.. DHCP), it needs to work on both ad hoc networks and managed networks without explicit host configuration.  That's not to say that the ability to do manual configuration isn't extremely desirable, but it's not something that should need to be used in normal cases.
--

I tried enlightenment but it kept crashing.

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 13:47:26 -0500

On 01/22/2003 13:33, "Keith Moore" <[email-masked]> wrote:

> 
> For an autoconfiguration solution to be significantly more useful than what we
> have now (i.e.. DHCP), it needs to work on both ad hoc networks and managed
> networks without explicit host configuration.  That's not to say that the
> ability to do manual configuration isn't extremely desirable, but it's not
> something that should need to be used in normal cases.

Manual does not mean "Not automatable". I automate manual commands as a
hobby.

But I have MAJOR objections to the automation solutions proposed. Requiring
a command to be specifically run, removes a lot of those objections...well,
actually, all of them, as long as the user is notified that v4LL has been
turned off.

You also don't have to create some change to DHCP, some 'other' network
notification mechanism. The infrastructure to support this is already there.

john

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