Subject: One last attempt to illustrate my concerns

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 10:03:53 -0500

Okay, ignoring a bunch of ad hominem attacks on my network knowledge.

Preexisting conditions:

I have an internet connection

This internet connection gives me a global address

This address is assigned via DHCP (the most common method).

I only have one computer, so I don't need a router of any kind.

I only have one physical interface on the computer. Ethernet.

Now, I buy a printer.

The printer is a zeroconf printer.

It supports v4LL addressing.

It too only has an ethernet interface

I buy a little switch, a 4 - port 10/100 job.

It is not a router. It is only a switch. It provides no configuration
capabilities. None. I don't need them. I don't want them. I'm not a geek (in
this example), I just want to print, and I'm already using a lot of USB
devices, so I don't want to add another one.

Now, we get interesting.

My computer, since it is configured via DHCP has its v4LL capabilities
disabled. It can not use a v4LL address. Period. This is what disabled
means. Not functional.

I don't want to pay for another address from my ISP. It's not that I'm
trying to steal from them. I just only want to print at home. Not from Pago
Pago, or Botswana, or France. Just from home.

But now I have a problem.

I can't use v4LL, because I am using DHCP for my address configuration, and
v4LL is (according to many on this list), not going to be available on my
computer until such time as I am no longer getting my IP configuration via
DHCP.

But now I can't print unless I have my printer configured via DHCP too.

So now, I have to either pay for an additional address, *or*, legally or
not, buy a router of some kind that can be an interface to the public
network. I may have to use DHCP for my two device network. I may not. The
point is, thanks to v4LL being off, I now HAVE to get another piece of
equipment, or deal with my printer being globally visible.

THAT is bogus. It's requiring the home user to now become far more aware of
networking than they should have to. THAT is why I want v4LL to just be on.

I really can't say it any clearer than that.

john

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

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Jan 2003 10:16:00 -0500

> disabled. It can not use a v4LL address. Period. This is what disabled

You are making a possibly unwarranted assumption. DHC communicates two
kinds of parameters. Those having global scope (i.e., impact the node
as a whole). The other kind of parameter are those that only impact
the interface on which the configuration information came on.

My assumption is that a DHCP option saying "don't use LL addressing"
would only apply to the interface where DHC was run. (But in anycase,
this level of detail would need to be fleshed out). Thus, recieving
such an option on interface X would not imply LL is not to be run on
other interfaces.

Thomas

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 10:29:59 -0500

> such an option on interface X would not imply LL is not to be run on

Ah, but there are a lot of computers in homes with only one interface. Which
is where the problems with turning off LL in the face of DHCP lie. And I
don't like unspecified assumptions in a standard. It causes problems, just
ask the Kerberos people.

I fully realize that there are things that v4LL on all the time will break.
Having seen that they are what could easily be considered edge cases for
simple networks, and that these applications can be updated to deal with
this, then I simply cannot agree that turning off v4LL as an automatic
function of other configurations is a good idea.

Now, since there are times when you would want this shut off, any earlier
objections I may have had to requiring a manual shutoff are removed. There
are reasons, outside of edge case clustering apps, (I was reminded about
working in places like Livermore, and other extreme security environments by
some friends complaining about having to remove wireless cards to simply
enter the building,) where it needs to be off. A manual config provides this
in an obvious, noticeable way. Along with a reminder dialog on (re)boot,
wake up, interface (re)configuration, my issues with this would be settled
nicely.

john

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 22 Jan 2003 10:34:02 -0500

> such an option on interface X would not imply LL is not to be run on

I believe the scenario is supposed to look like this:

                     ISP
                      |
                      |
                    +---+
                    |hub|
                    +---+
                     | |
                     | |
          printer ---+ +--- PC
   (169.254.38.54)         (67.45.33.4)

So, here is my view.  The PC could honor the "no v4LL" on the
interface and still reach the printer.  The PC could simply add
a route for 169.254/16 for each interface.  This can be done
without configuring a v4LL address on the interface.  And it
would cause the PC's IP stack to arp for the address in question.
The user would have to specify the printer by its IP address, but
that is not a big deal.

Brian

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 10:43:30 -0500

> The user would have to specify the printer by its IP address, but

Well, that actually is a big deal, but that's for service discovery and
mDNS, not v4LL.

But if you're going to go through all the trouble to communicate with v4LL
devices, why not just take the last step and give them the address too? It's
simpler, and easier to plan for if it's *always* there.

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 11:06:26 -0500

> disabled. It can not use a v4LL address. Period. This is what disabled

no, this is not what was intended.  

what was intended is if your computer gets an address from DHCP it should not attempt to acquire a v4LL address.  however, the lack of a v4LL address should not stop it from attempting to talk to a v4LL address on one of its interfaces.

--

However this did cause me to realize a problem with the idea that any DHCP service should suffice to disable v4LL.

I have a DSL modem at home.  As shipped, that modem had a DHCP server that assigned a RFC 1918 address to the first host that asked for an address.  It would do NAT (arrgh) between that address and the address assigned to the DSL line by the ISP.[*]  However it would NOT NAT for multiple devices and it woudl NOT honor any subsequent DHCP requests for addresses by other hosts on the network.

So imagine a home network with a DSL modem like mine, an Ethernet hub, and two hosts - a windows or mac box and a zeroconf printer.  If the windows or mac box asks DHCP for an address first, then all is well - the windows or mac box can talk externally, and it can talk to the printer's v4LL address.  On the other hand if the printer asks DHCP for an address first, then the printer can accept connections from anywhere in the network, but the windows or mac box will be isolated.  And the poor clueless user has to reboot the cable modem, *then* reboot the windows or mac box, or something.  That's a lousy arrangement.

Now this is a limited sample space, and maybe that's just an anomaly with this one DSP modem, but I've heard that this kind of behavior is common.  If so then what we need is some more explicit way for a network to say "don't use LL" than just the presence of a DHCP server.

Keith

[*] fortunately I was able to configure the modem to operate in PPPoE mode, which gets rid of the NAT, and allows me to run 6to4 to talk to my home machines.

---

From: "Subrata Goswami" <[email-masked]>
Date: Wed, 22 Jan 2003 08:11:18 -0800

Well,  a $30.0 router/nat box  from Liksys/Dlink/3Com after your DSL
modem
should give you access to many more 192.168/16 IP addresses.  

Subrata

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Keith Moore
> Sent: Wednesday, January 22, 2003 8:06 AM
> To: John C. Welch
> Cc: [email-masked]; [email-masked]
> Subject: problems with using DHCP (was: one last attempt to 
> illustrate my concerns)
> 
> 
> 
> what was intended is if your computer gets an address from 
> DHCP it should not attempt to acquire a v4LL address.  
> however, the lack of a v4LL address should not stop it from 
> attempting to talk to a v4LL address on one of its interfaces.
> 
> --
> 
> However this did cause me to realize a problem with the idea 
> that any DHCP service should suffice to disable v4LL.
> 
> I have a DSL modem at home.  As shipped, that modem had a 
> DHCP server that assigned a RFC 1918 address to the first 
> host that asked for an address.  It would do NAT (arrgh) 
> between that address and the address assigned to the DSL line 
> by the ISP.[*]  However it would NOT NAT for multiple devices 
> and it woudl NOT honor any subsequent DHCP requests for 
> addresses by other hosts on the network.
> 
> So imagine a home network with a DSL modem like mine, an 
> Ethernet hub, and two hosts - a windows or mac box and a 
> zeroconf printer.  If the windows or mac box asks DHCP for an 
> address first, then all is well - the windows or mac box can 
> talk externally, and it can talk to the printer's v4LL 
> address.  On the other hand if the printer asks DHCP for an 
> address first, then the printer can accept connections from 
> anywhere in the network, but the windows or mac box will be 
> isolated.  And the poor clueless user has to reboot the cable 
> modem, *then* reboot the windows or mac box, or something.  
> That's a lousy arrangement.
> 
> Now this is a limited sample space, and maybe that's just an 
> anomaly with this one DSP modem, but I've heard that this 
> kind of behavior is common.  If so then what we need is some 
> more explicit way for a network to say "don't use LL" than 
> just the presence of a DHCP server.
> 
> Keith
> 
> [*] fortunately I was able to configure the modem to operate 
> in PPPoE mode, which gets rid of the NAT, and allows me to 
> run 6to4 to talk to my home machines.
>

---

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

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

> what was intended is if your computer gets an address from DHCP it should not
> attempt to acquire a v4LL address.  however, the lack of a v4LL address should
> not stop it from attempting to talk to a v4LL address on one of its
> interfaces.

Okay, but now we are getting into this odd 'v4LL' is kind of off, but kind
of on. And if you have a computer with only one interface, (common enough, I
have a dualie 800 G4 with only one interface, it's a UTGOTY server among
other things), then the 'oh, you can use another interface' is not an
option.

Look, I understand that stuff will break if you have v4LL addresses all the
time. That's a pain, but heck, v6 will break stuff, DHCP broke stuff too.
All change breaks stuff. Such is life.

But, one of the things I *hated* coding around, (when I was silly enough to
program for a living), was 'sometimes'. Sometimes is a real pain to deal
with. Always is a pain too, but planning for 'always' and dealing with
'always' is *far* easier than dealing with 'sometimes'.

If you have the shutoff be manual only, with proper user notification, then
you get far closer to the best of both worlds, and you get 'always' far more
often.

> 
> Now this is a limited sample space, and maybe that's just an anomaly with this
> one DSP modem, but I've heard that this kind of behavior is common.  If so
> then what we need is some more explicit way for a network to say "don't use
> LL" than just the presence of a DHCP server.

<sigh>...it's not uncommon at all. It's real common in fact. Which is why a
manual shutoff is going to be the simplest, and most elegant way to handle
this.

john

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

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Jan 2003 23:26:11 +0700

Date:        Wed, 22 Jan 2003 10:43:30 -0500
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

  | But if you're going to go through all the trouble to communicate with v4LL
  | devices,

It is no trouble, it "just works".   If you don't understand how & why,
then .... (rewind to an earlier message).

  | why not just take the last step and give them the address too? It's
  | simpler, and easier to plan for if it's *always* there.

It isn't simpler.   Actually allocating the address is easy enough
(though unnecessary), but now the node has two addresses, and both it
and every other node, has to continually try to work out which one of
the two should be used.   That isn't simpler, for anything.

kre

---

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

> then .... (rewind to an earlier message).

I understand how and why. I just find it an overly complex method to avoid
something and still use it.

> the two should be used.   That isn't simpler, for anything.

The methodologies for this are well understood, and provides a more
consistent set of circumstances.

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:04:29 -0500

On Wed, 22 Jan 2003 08:11:18 -0800
"Subrata Goswami" <[email-masked]> wrote:

> modem should give you access to many more 192.168/16 IP addresses.  

two wrongs don't make a right, and two NATs don't let applications that need a global address work.

-- 
I tried enlightenment but it kept crashing.

---

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

> I fully realize that there are things that v4LL on all the time will
> break. Having seen that they are what could easily be considered edge
> cases for simple networks, and that these applications can be updated
> to deal with this, then I simply cannot agree that turning off v4LL as
> an automatic function of other configurations is a good idea.

The cases that break are not edge cases (or at least, that characterization seems rather arbitrary), and the applications cannot always be updated to deal with this, particularly when they are expected to deal with a mixture of devices some of which have ambiguous addresses and some of which don't. 

> Now, since there are times when you would want this shut off, any
> earlier objections I may have had to requiring a manual shutoff are
> removed.

Manual shutoff is desirable for devices that can be manually configured, but not sufficient.  There needs to be some way for the network to specify whether LL is allowed on the link.

---

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

> But if you're going to go through all the trouble to communicate with
> v4LL devices, why not just take the last step and give them the
> address too? 

1. because this forces apps to deal with the extra complexity of being aware of network topology and having to choose between addresses of different scopes.

2. because the addresses will leak into areas of the network in which they are not valid.

---

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

> > Now this is a limited sample space, and maybe that's just an anomaly
> > with this one DSP modem, but I've heard that this kind of behavior
> > is common.  If so then what we need is some more explicit way for a
> > network to say "don't use LL" than just the presence of a DHCP
> > server.
> 
> <sigh>...it's not uncommon at all. It's real common in fact. Which is
> why a manual shutoff is going to be the simplest, and most elegant way
> to handle this.

manual shutoff doesn't scale.  and it sort of defeats the purpose of having zero configuration, doesn't it? 

I think what this means is that we need an explicit indication from the network to turn LL off or on; in the absence of any indication about LL from the network it can default to on.  this would let a network disable LL, it would also let a network assign routable addresses instead of LL addresses.  

but the mere presence of DHCP should not be taken as an indication one way or another of whether LL should be used.

---

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

>   Actually allocating the address is easy enough
> > (though unnecessary), but now the node has two addresses, and both
> > it and every other node, has to continually try to work out which
> > one of the two should be used.   That isn't simpler, for anything.
> 

there are no methodologies that work, at least not without imposing some other constraints - e.g. that every node also have a global address.

---

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

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

> 1. because this forces apps to deal with the extra complexity of being aware
> of network topology and having to choose between addresses of different
> scopes.
> 

Okay...so compromise...support manual only control, and I'll not object to
turning v4LL off...I just don't like an unauthenticated, random server able
to screw up my settings. Manual avoids this.

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: Wed, 22 Jan 2003 13:31:48 -0500

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

> Manual shutoff is desirable for devices that can be manually configured, but
> not sufficient.  There needs to be some way for the network to specify whether
> LL is allowed on the link.

Ah, but make it part of the standard. Then, it has to be in there, (well, as
much as anything else). The network admin *can* do this via any number of
mechanisms that allow for remote command execution on the devices in
question. Or, for things like printers, it can be an option on a web or
command line config program. Heck, you could even automate it:

For example, on Mac OS X, Sustainable Softworks has a firewall product that
can kick off applescripts when a rule is violated...

So, when v4LL traffic is detected, you run an Applescript that uses SSH to
remotely log into the box, and kill v4LL. You can also send an email to the
registered user of the box. If the system is a transient/visiting system,
and you get an error when SSH'ing into the box, you could, as an error
handler, run a script that instructs your managed switches to ignore all
traffic from that MAC address.

The user is notified, and the access mechanism is authenticated. I'm happy.
You can easily keep v4LL off of your network. You're happy, or should be.

It's *SIMPLE**...everyone should like that.

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: Wed, 22 Jan 2003 13:42:12 -0500

> zero configuration, doesn't it?

It scales extremely well, as you can easily run remote apps on *thousands*
of machines at once if need be. It also doesn¹t need to be continuously told
to stay off. Managed switches can identify violators of the policy, as can
any number of network management apps.

It also doesn't have to violate zeroconf. The devices ship with it on by
default. Always...so unless you turn it off, it's zeroconf. If you turn it
off, you had to *manually*, at some point do so. Which means a conscious
decision was made to do so.  Since it's a manual decision, it lets off mean
OFF. No silliness with ARPs and what not. LL is on, you get ALL of LL. LL is
off, you get NO LL.

> 
> I think what this means is that we need an explicit indication from the
> network to turn LL off or on; in the absence of any indication about LL from
> the network it can default to on.  this would let a network disable LL, it
> would also let a network assign routable addresses instead of LL addresses.

You can do this with my method, only you get some side benefits pretty much
for free...like authentication, permissions controls, encryption. What's not
to like?

> another of whether LL should be used.

On that, we are in complete agreement.

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:44:03 -0500

On Wed, 22 Jan 2003 13:33:56 -0500
"John C. Welch" <[email-masked]> wrote:

> >> But if you're going to go through all the trouble to communicate
> >with> v4LL devices, why not just take the last step and give them the
> >> address too? 
> > 
> > 1. because this forces apps to deal with the extra complexity of
> > being aware of network topology and having to choose between
> > addresses of different scopes.
> > 
> Okay...so compromise...support manual only control, and I'll not
> object to turning v4LL off...I just don't like an unauthenticated,
> random server able to screw up my settings. Manual avoids this.

Zero configuration inherently implies not having authentication, because without configuration there's no way to tell a device who to trust and who to ignore.

So in the absence of explicit configuration there is no way for a device to know whether a response to  its address claim or address request is acting on behalf of the network, or whether it is one that is trying to subvert the local network's policy.   A rogue responder could either be trying to disable LL when the network's policy was to permit it, or it could be trying to enable LL when the network's policy was to forbid it.
And there's no reason to assume that the breakage resulting from using LL when it's not permitted is always or even highly likely to be better than the breakage resulting from refusing to use LL when it is permitted.

---

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

> > Manual shutoff is desirable for devices that can be manually
> > configured, but not sufficient.  There needs to be some way for the
> > network to specify whether LL is allowed on the link.
> 
> Ah, but make it part of the standard. Then, it has to be in there,
> (well, as much as anything else). The network admin *can* do this via
> any number of mechanisms that allow for remote command execution on
> the devices in question. 

Well, we'd need to pick a standard mechanism that every device would implement, having to support a different one for each device would be a nightmare.  And it would therefore need to be lightweight.  And it's hard to see how to get useful authentication in such a mechanism unless there's a way to configure each device with a password or some such.
And it would be less dirsuptive to have the device learn an appropriate address *before* using an LL address, rather than having to have to wait for the device to generate traffic and then kick it.

That, and there's no way to require manual shutoff for devices that lack any means of manual input.
-- 
I tried enlightenment but it kept crashing.

---

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

> It scales extremely well, as you can easily run remote apps on
> *thousands* of machines at once if need be.

I think we're using the word "manual" in different ways.  I'm using it a way that means that someone has to physically touch that specific device in order to alter its behavior, rather than sending it a signal over a network.

---

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

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

> Zero configuration inherently implies not having authentication, because
> without configuration there's no way to tell a device who to trust and who to
> ignore.

Right...so we should therefore not require any authentication anywhere when
dealing with Zeroconf?

> 
> So in the absence of explicit configuration there is no way for a device to
> know whether a response to  its address claim or address request is acting on
> behalf of the network, or whether it is one that is trying to subvert the
> local network's policy.   A rogue responder could either be trying to disable
> LL when the network's policy was to permit it, or it could be trying to enable
> LL when the network's policy was to forbid it.

Which is a reason why unauthenticated modification to LL status is such a
BAD idea...it's too easy to subvert either way.

> And there's no reason to assume that the breakage resulting from using LL when
> it's not permitted is always or even highly likely to be better than the
> breakage resulting from refusing to use LL when it is permitted.

That's why having to make a conscious decision to kill it, or turn it back
on, is a better idea.

john

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

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 22 Jan 2003 11:10:30 -0800

I must be missing something. I don't see how some method other than 
DHCP to turn off IPv4LL would solve the problem described by Keith. 
Maybe I'm missing something? If the NAT box ignores the Mac and PC DHCP 
requests for addresses then both boxes should self assign IPv4LLs. The 
mere presence of a DHCP server should not prevent a device from self 
assigning an IPv4LL. A device should not self assign an IPv4LL if it 
does not get an address through some other configuration method (i.e. 
no DHCP response). There is no way for the Mac or PC to know that there 
is a DHCP server, right? I'm not intimately familiar with DHCP, but I 
was under the impression that if a DHCP server didn't want to give you 
an address, it wouldn't respond with a "no, go away", it would simply 
fail to respond at all.

Robert Elz argued we should distinguish between the case where we're 
refused an address and the case where there is no DHCP server. Robert 
Elz seemed to suggest that we should not acquire an IPv4LL in the case 
where we're refused an address. Is there an easy way to tell the 
difference? Does it matter?

I don't think we should put unnecessary restrictions in to the IPv4LL 
draft to satisfy deluded administrators that think not handing out a 
DHCP address is a way to keep unauthorized people from using the 
network. If a device does get an IPv4LL address, the device will still 
be unable to communicate with anything off of the local link. An IPv4LL 
address will not instantly give access to the global internet, only 
other devices on the local link. Those devices are not protected by not 
automatically assigning an address on the local link to unauthorized 
devices. Once a device has access to the link, there is nothing to 
prevent it from using any number of protocols (AppleTalk, IPX, IPv6) to 
communicate with other devices on that link.

-josh

On Wednesday, January 22, 2003, at 08:06 AM, Keith Moore wrote:

> However this did cause me to realize a problem with the idea that any 
> DHCP service should suffice to disable v4LL.
>
> I have a DSL modem at home.  As shipped, that modem had a DHCP server 
> that assigned a RFC 1918 address to the first host that asked for an 
> address.  It would do NAT (arrgh) between that address and the address 
> assigned to the DSL line by the ISP.[*]  However it would NOT NAT for 
> multiple devices and it woudl NOT honor any subsequent DHCP requests 
> for addresses by other hosts on the network.
>
> So imagine a home network with a DSL modem like mine, an Ethernet hub, 
> and two hosts - a windows or mac box and a zeroconf printer.  If the 
> windows or mac box asks DHCP for an address first, then all is well - 
> the windows or mac box can talk externally, and it can talk to the 
> printer's v4LL address.  On the other hand if the printer asks DHCP 
> for an address first, then the printer can accept connections from 
> anywhere in the network, but the windows or mac box will be isolated.  
> And the poor clueless user has to reboot the cable modem, *then* 
> reboot the windows or mac box, or something.  That's a lousy 
> arrangement.
>
> with this one DSP modem, but I've heard that this kind of behavior is 
> common.  If so then what we need is some more explicit way for a 
> network to say "don't use LL" than just the presence of a DHCP server.
>
> Keith

---

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

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

> Well, we'd need to pick a standard mechanism that every device would
> implement, having to support a different one for each device would be a
> nightmare.  And it would therefore need to be lightweight.

Nope...leave it up to the vendor. Most unix -based OS's would get either
'v4LL.conf' or a new switch to ifconfig. Probably take about a week to do,
based on past experience. Windows, the same way. You wouldn't want to tell
them how, just what. It's not like you can force anyone to obey a standard
anyway, but this is pretty simple compared to DHCP/other - based schemes.

> And it's hard to 
> see how to get useful authentication in such a mechanism unless there's a way
> to configure each device with a password or some such.

Well, lets see...I can do it for JetDirect print servers, I can do it for
anything with a web interface, Mac OS X and most Unixen require SSH, Windows
supports PPTP as a part of the OS....

> And it would be less dirsuptive to have the device learn an appropriate
> address *before* using an LL address, rather than having to have to wait for
> the device to generate traffic and then kick it.

Take at most three packets to detect, about five minutes to run the script,
and is only going to be an issue for transient or misconfigured devices
anyway.

> That, and there's no way to require manual shutoff for devices that lack any

There are VERY few networked devices that don't have some means of remote
access bit it http, SSH, even, (ugh), telnet. Again, the infrastructure is
*there*.

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: Wed, 22 Jan 2003 14:19:01 -0500

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

> I think we're using the word "manual" in different ways.  I'm using it a way
> that means that someone has to physically touch that specific device in order
> to alter its behavior, rather than sending it a signal over a network.

Ahh...no, not at all. I'm using it in the sense that there has to be a
concious decision made, and a manual action taken. That action can be
initiated from a network management console, but it is not just run because
you happen to see a DHCP server.

By using a manual process, such as say, a new switch to ifconfig, you can
remotely execute that manual action, BUT you can use things like SSH to
ensure that only authorized, authenticated sources can take that action.

You get what you want, I get what I want, zeroconf ships as zeroconf by
default, the script kiddies can't build v4LL DeathTraps...sounds good to me.

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: Wed, 22 Jan 2003 14:26:25 -0500

On 01/22/2003 14:10, "Joshua Graessley" <[email-masked]> wrote:

> network.

I don't think DHCP should be in the business of deciding which config is to
be used. It provides one form of config, it shouldn't be used to turn others
off...it's too insecure to do this. So I want authentication and
authorization.

A manual on/off switch provides this, since you use things like SSH for
remote login/execution *anyway*.

I also think that if I, as a network admin, want v4LL off my network, I want
to know that It's NOT THERE AT ALL. No communication with v4LL addresses
whatsoever. 

A manual on/off switch provides this.

I also don't want to lose my v4LL just because my idiot brother has his
laptop set up as a DHCP server by accident.

A manual on/off switch prevents this.

Finally, if I want zeroconf on out of the box, then I want it ON...no
mucking about.

A manual on/off switch allows for this.

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 14:33:01 -0500

> > Zero configuration inherently implies not having authentication,
> > because without configuration there's no way to tell a device who to
> > trust and who to ignore.
> 
> Right...so we should therefore not require any authentication anywhere
> when dealing with Zeroconf?

The intersection between "zero configuration technologies" and
authentication is the null set.  

On the other hand, if you want to develop an architecture that allows
devices to automatically adapt to a variety of network
situations (including varying needs for security and varying policies
about the default level of access) with a minimum of configuration, then
authentication probably does need to be part of that picture.  But this
would be a drastic departure from the way this group has been working. 

> Which is a reason why unauthenticated modification to LL status is
> such a BAD idea...it's too easy to subvert either way.

But assuming that LL is permitted is also a bad idea.

> That's why having to make a conscious decision to kill it, or turn it
> back on, is a better idea.

I am assuming that any decision on the part of a network administrator
to explicitly permit or forbid LL on a network would be a conscious one,
though it would not be acceptable to force that administrator to make
such decisions on a per-device basis.  

At the same time, it is technically infeasible for such indications to
be authenticated if the device cannot be reliably configured as to which
authorities to trust.
-- 
I tried enlightenment but it kept crashing.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 14:36:55 -0500

> > implement, having to support a different one for each device would
> > be a nightmare.  And it would therefore need to be lightweight.
> 
> Nope...leave it up to the vendor.

completely unacceptable.  without a uniform means of disabling LL, it is
a denial-of-service attack on networks and applications.  and you seem
to be thinking in terms of conventional hosts when at least as much of
the problems is hosts without a manual input.

> > And it's hard to 
> > see how to get useful authentication in such a mechanism unless
> > there's a way to configure each device with a password or some such.
> 
> Well, lets see...I can do it for JetDirect print servers, I can do it
> for anything with a web interface, Mac OS X and most Unixen require
> SSH, Windows supports PPTP as a part of the OS....

I'm getting the impression you don't know what authentication is.

> > And it would be less dirsuptive to have the device learn an
> > appropriate address *before* using an LL address, rather than having
> > to have to wait for the device to generate traffic and then kick it.
> 
> Take at most three packets to detect, about five minutes to run the
> script, and is only going to be an issue for transient or
> misconfigured devices anyway.

that doesn't mean that they're few in number.

> There are VERY few networked devices that don't have some means of
> remote access bit it http, SSH, even, (ugh), telnet. 

how do you talk to a device when it doesn't even have a valid address?
(and no, LL doesn't work - that forces you to configure each device from
its own link)

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 14:49:44 -0500

> the problems is hosts without a manual input.

Reality check...without everyone running the same OS, uniformity will never
happen *anyway*.

And you confuse manual with physical.

> I'm getting the impression you don't know what authentication is.

Authentication: to require a user to identify themselves against a
predetermined criteria that determines their ability to access a resource.
This can be everything from a simple password file to a Kerberos realm. So,
since you can require a userID and password, even with JetDirect, you can
force *some* authentication.

> that doesn't mean that they're few in number.

Won't matter. Three to three thousand, this kind of stuff is run every day,
breaks nothing, changes no standards.

> (and no, LL doesn't work - that forces you to configure each device from

Initial out of the box config for devices without a physical input device
would require a one time hookup over the LL. Which would be there by
default. But then, you have to take it out of the box physically *anyway*,
and configure other operational aspects *anyway*, so this is not onerous by
any stretch of the imagination. BUT, you would ONLY have to do this if you
are *disabling* v4LL. If you weren't, then you wouldn't do this anyway.

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 14:57:05 -0500

I am not sure I even understand what you are saying, because some of the
statements seem to be contradictory.  So rather than trying to
respond in detail to statements that I don't think I understand, let me
see if it helps to rephrase what I'm saying:

1. Networks need a way to say to devices "don't use LL" (because LL
causes problems) and optionally "use this other address" (so that
autoconfiguring devices will continue to function)

2. Having autoconfiguring devices try DHCP first will not interoperate
well with certain DSL modems.   Maybe that's not this group's problem,
but we should at least be aware of it.  

Partially because of #2, it might be that an explicit indication from
DHCP(or some other protocol) that means "don't use LL" would be better
than interpreting a DHCP response to an address request as an implicit
indication that LL should not be used.  Or not.  I see this as a
question of which is worse:

a. Accidental use of LL on a managed network, with all of the problems
that this causes for applications, or

b. Failure of home networks that use such DSL modems in the presence of
autoconfiguring devices.

Offhand, I tend to think that the second case is worse.  The managed
network presumably has someone with expertise and perhaps diagnostic
tools who can turn on the "disable LL" signal if/when it causes
problems, whereas the home network user has neither of these.  So it's
better to break the managed network, *provided* there's a way in the
standard for the managed network to fix the problem.

> DHCP address is a way to keep unauthorized people from using the 

As for this, as I explained earlier - it is not for this WG to decide
whether existing networks' access control methods for IP networks
are useful or secure, nor to decide that it's okay to subvert them.
This WG is proposing changes to an long-existing, widely-deployed,
heavily-used communications interface.  It therefore has the burden of
minimizing harm to existing uses of that interface.

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 14:57:49 -0500

> authentication is the null set.

Missing the point...i'm talking about authentication to *turn it off*. If
you want it, you don't care. If you *don't* want it, then you turn it off,
and configure it some other way.

> But assuming that LL is permitted is also a bad idea.

But you aren't assuming it's *permitted* under my proposal. You don't *have*
to. You are only assuming that it's *present*. If you *don't* want it, then
you turn it off, and it stays off. So you don't have to have it on if you
don't want to. At all.

> such decisions on a per-device basis.

Not if the mere presence of DHCP kills it. As long as it's easy to automate
killing v4LL, then I don't see a lot of network admins minding. Hell, you
end up doing per-device config for *everything* anyway, network or not. You
config users, you config capabilities...so this is one more, very fast, very
efficient thing. Not a big deal. I can do the script in five minutes.

> be authenticated if the device cannot be reliably configured as to which

You get the device out of the box and set the password for it. This is a
common task for *all* new devices on a network for any network admin. So we
aren't creating any problems here.

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 14:58:22 -0500

> BUT you can use things like SSH to ensure that only authorized,
> authenticated sources can take that action.

actually no.  SSHing to a device that isn't configured to know which
authentication tokens to accept and which to reject is not
authentication.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 15:03:30 -0500

> > completely unacceptable.  without a uniform means of disabling LL,
> > it is a denial-of-service attack on networks and applications.  and
> > you seem to be thinking in terms of conventional hosts when at least
> > as much of the problems is hosts without a manual input.
> 
> Reality check...without everyone running the same OS, uniformity will
> never happen *anyway*.

reality check - we have hundreds of millions of machines on the planet,
of varying operating systems, all supporting TCP and IP and lots of
other protocols.  you're insisting on uniform implementation of LL but
not on a uniform way of disabling LL.

> And you confuse manual with physical.

look up the word in a dictionary.  hint: the root of "manual" is "man"
which means "hand".

> predetermined criteria 

so how do you get a box which isn't configurable to have predetermined
criteria that are appropriate to its network?

> > how do you talk to a device when it doesn't even have a valid
> > address?(and no, LL doesn't work - that forces you to configure each
> > device from its own link)
> 
> Initial out of the box config for devices without a physical input
> device would require a one time hookup over the LL. 

not acceptable.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 15:06:53 -0500

On Wed, 22 Jan 2003 14:57:49 -0500
"John C. Welch" <[email-masked]> wrote:

> >> Right...so we should therefore not require any authentication
> >anywhere> when dealing with Zeroconf?
> > 
> Missing the point...i'm talking about authentication to *turn it off*.

no you are missing the point.  there is no way to securely authenticate
to a device which has no explicit configuration about which
authentication tokens to accept.  none at all.

and even if you do explicitly configure the device about what to accept
(which does not scale), that configuration is wrong as soon as that
device moves to another network.

> > I am assuming that any decision on the part of a network
> > administrator to explicitly permit or forbid LL on a network would
> > be a conscious one, though it would not be acceptable to force that
> > administrator to make such decisions on a per-device basis.
> 
> Not if the mere presence of DHCP kills it.

okay fine, but we're agreed (perhaps for different reasons) that the
mere presence of DHCP should not kill LL.

---

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

> authentication tokens to accept and which to reject is not

It's not perfect, but it beats the hell out of any DHCP server being able to
pooch your setttings.

john

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

---

From: julien maisonneuve <[email-masked]>
Date: Wed, 22 Jan 2003 21:10:49 +0100 (MET)

> Date: Wed, 22 Jan 2003 14:36:55 -0500
> From: Keith Moore <[email-masked]>
> 

But what if your attacker happens to have a stack that won't listen to
you disabling requests and ignores DHCP altogether ?
This mechanism doesn't give you any additional security.

						Julien.

---

From: julien maisonneuve <[email-masked]>
Date: Wed, 22 Jan 2003 21:11:52 +0100 (MET)

> Date: Wed, 22 Jan 2003 14:26:25 -0500

Just a small throught : when you buy a printer, or any such device
that has specific properties, you often have to install some sort of a
driver that knows how to talk with it and configure it properly (most
devices are shipped with a CD).
This driver is perfectly able to switch v4ll ON whenever it is
required.
So why not use your approach (manual setting, no network decision
which is too easily subverted), and ship computers with v4ll OFF
as a default ? I suppose a printer and other dumb devices should be
shipped with v4ll ON to avoid any config.

						Julien.

---

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

> not on a uniform way of disabling LL.

You can't get a uniform implementation of TCP/IP, what makes you think your
proposal will magically get done in a uniform manner. My proposal only
requires an on/off switch. It allows vendors to implement it in the fashion
that will work best for their customers.

> look up the word in a dictionary.  hint: the root of "manual" is "man"

I *manually* configure my Unreal Tournament server from my bedroom, it's in
my living room...no KVM, and I'm not plastic man...but, since you forget
that every word has multiple meanings:

" operated by human effort rather than by a machine, computer, or type of
power

Encarta® World English Dictionary © 1999 Microsoft Corporation. All rights
reserved. Developed for Microsoft by Bloomsbury Publishing Plc."

Definition 3. THAT is the one I'm using.

> criteria that are appropriate to its network?

How do you configure a new box now? Answer, you do it manually, for the
initial setup. Your computer didn't come from the factory knowing who you
were, your userID or your password. ALL networkable devices have SOME way to
MANUALLY configure them...otherwise, you can't change ANY setting, which
makes them pretty useless.

>> device would require a one time hookup over the LL.

Give me one device that comes out of the box with every setting configured
for every possible situation.

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: Wed, 22 Jan 2003 15:20:16 -0500

> authentication tokens to accept.  none at all.

It's MORE secure than random servers killing it.

> device moves to another network.

Bullshit. Network admins do this trick on thousands of devices *daily*...it
scales amazingly well. Your second sentence is wrong if you tell it "Don't
use v4LL, use DHCP". If you use manual addresses, then you assume the
responsibility of changing that address the hard way ANYWAY.

> mere presence of DHCP should not kill LL.

Oh definitely. I think it's an amazingly convoluted and bad idea.

But I at least have a solution that I can show you a direct analog for
*now*, this instant. Do you have something similar?

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: Wed, 22 Jan 2003 15:21:42 -0500

> shipped with v4ll ON to avoid any config.

v4LL on is then zeroconf, v4LL off is not. As you just pointed out, changing
it to off takes about ten seconds. That way, it's there, until/unless you
don't want it, then it is not.

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 15:23:29 -0500

On Wed, 22 Jan 2003 21:10:49 +0100 (MET)

> This mechanism doesn't give you any additional security.

then (assuming other devices are well-behaved) the attacker is
marginalized and easier to detect.

it is understood that an attacker may be ill-behaved.  what is
unacceptable is having the standard encourage poor behavior on the part
of devices.

also, by "denial-of-service attack" above, I was referring to the
effect of having large numbers of hosts on managed networks speaking LL,
rather than some specific, intentional attack.

---

From: Alex Karahalios <[email-masked]>
Date: Wed, 22 Jan 2003 13:23:37 -0700

Hi Keith,

Also manual (hand) could mean your hand typing on a keyboard sending 
commands through the network. In reality the semantics of the word 
"manual" should not deter a vendor for providing a means of disabling 
LL.

For example, the device which I am developing, has a web interface 
which allows configuration. I would consider this manual in the sense 
that a person has to use their hands to affect a change. The device 
also has a physical factory default button which can be manipulated to 
set the device to factory defaults. I think this is manual also.

Alex Karahalios

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 15:29:45 -0500

On Wed, 22 Jan 2003 13:23:37 -0700

> "manual" should not deter a vendor for providing a means of disabling 

I hope we can manage to have a clear standard without having to rely on
fine distinctions in the English language, especially because many
implementors will not be native English speakers. But there's clearly a
difference between being able to specify policy on LL use on a
per-network basis and having to configure each device individually,
regardless of whether or not someone's hands have to touch that device.

As one particular example, you can't automate configuration of
nework devices if you have to arrange for each device to be hooked to a
link that is shared with a computer that is doing the configuration. 
Whether that's "manual" or not, that's not an acceptable way to dictate
policy.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 15:30:42 -0500

> It's not perfect, but it beats the hell out of any DHCP server being
> able to pooch your setttings.

from a security point-of-view, it's exactly the same level of
vulnerability.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 15:32:18 -0500

> devices are shipped with a CD).

let's not use printer vendors' mistakes to justify other mistakes.

it's perfectly reasonable to expect printers to work out of the box, and
implement standard spooling protocols and page description
languages, without having to install drivers.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 15:34:22 -0500

> > no you are missing the point.  there is no way to securely
> > authenticate to a device which has no explicit configuration about
> > which authentication tokens to accept.  none at all.
> 

nope, it's the same problem.  the same random server that kills LL
via DHCP can "authenticate" to the device and kill LL that way.

and having the device save state about network configuration isn't
necessarily a good way to go anyway - the network should indicate to the
device what it's policies are.  the network is in a good position to
police those policies - it can filter traffic that doesn't follow them.

---

From: Rod <[email-masked]>
Date: Wed, 22 Jan 2003 14:34:51 -0600

John, do you realize what is being suggested is what Mac OS X 10.2 does 
right now? You seemed to defend it quite a bit previously, and now you 
don't seem to agree with standarizing the way OS X 10.2 does it.

I think you overlooked the description of the new proposal, and that's 
the reason why suddenly everyone who agreed with your points now seems 
to be in disagreement with you.

Here are some excrepts from Josh Graessley's messages that I beg you to 
carefully re-read and understand:

> Versions of Mac OS that support link-local will only acquire link 
> local addresses when configured to use DHCP and the DHCP server does 
> not respond. Various versions of the Mac OS will continue to send DHCP 
> requests. If a DHCP server does appear, the Mac will use the address 
> from the DHCP server but it will also continue to use the IPv4LL 
> address. The IPv4LL address is maintained to avoid unnecessarily 
> killing already established connections.
> The Mac OS will watch for link changed events to determine if DHCP 
> should be tried again or the IPv4LL address assignment should occur 
> again.

> If DHCP is present, I don't see any reason to acquire a LL address.
>
> On the other hand, if my machine or some other device for whatever 
> reason can't get an address from DHCP, or if it doesn't implement 
> DHCP, then I'd like it get an IPv4LL address. This assures me that I 
> have some way of communicating with the device. I don't want my 
> machine to silently refuse to acquire an address because some guy in 
> the dorm playing a prank is sending out some magic packet to disable 
> IPv4LL. I don't think we need to design a special protocol either.

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

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

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

Do you realize no changes have to be made to the DHCP spec to support 
this?

Do you realize the presence of a DHCP server will NOT kill IPv4LL on 
the link? It will only make hosts that aquire a global address NOT 
acquire an IPv4 LL address as well (since they DON'T need it!), and 
STILL be easily able to communicate with IPv4LL addresses by the way of 
ARP, which is NOT complicated, in fact that's how Mac OS X 10.2 does it 
today?

You seem to think that DHCP will absolutely kill IPv4LL on the link. It 
will not! Not acquiring an IPv4LL address when you already have a 
global one does not mean you won't be able to communicate with devices 
that do have one, either because they only work with IPv4LL or because 
they failed to get a global address. If you are concerned with them 
getting global addresses, you can disable this yourself most of the 
time (either on the device itself or on the dhcp server) and instead 
they will use an IPv4LL address.

I think this proposal goes in line with what you want, you just haven't 
taken the time to understand it well, and seem to be confusing it with 
earlier proposals of completely disabling IPv4LL with a dhcp option and 
whatnot. This is not the same. Your manual config suggestion seems 
unwarranted since I think if you understand these points you will see 
they cover the needs you have been addressing.

Thanks!

-Rod

---

From: julien maisonneuve <[email-masked]>
Date: Wed, 22 Jan 2003 21:46:05 +0100 (MET)

> Date: Wed, 22 Jan 2003 15:21:42 -0500

The point is not to qualify what is zeroconf and what is not, the
point is to minimize user intervention.
Switching it on on your computer requires no additional user
intervention if there is already a driver to install.

So far I do not share other people's concerns about v4ll (or rather I
don't think any of this will buy us anymore than an illusion of
security), so I do not specifically care whether it is on or off, but
a lot of people seem to care, and want it off unless there is a good
reason.

IF people want a v4ll switching mechanism, it should not be network
based because it is too easily subverted (and thus lead to denial of
service of linklocal devices), so it should be manual.

Several people want it off by default, and I can't see the problem
since drivers can change it to on at installation and/or runtime.

Also, it would be useful to say what we mean exactly by switching «it»
on or off. Giving a v4ll address to an interface is not the same thing
as sending packets to a v4ll address (which may take no more than a
local route). I am assuming that we talk about the former.

						Julien.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 15:54:04 -0500

> service of linklocal devices), so it should be manual.

nobody has given a convincing argument that "subverting" a device to not
use LL is any more likely than any of the myriad other kinds of
"subversion" that an attacker could use if the default were different.

and if by "manual" you mean "cannot be automated" then it doesn't solve
the problem.  

> since drivers can change it to on at installation and/or runtime.

the last thing I'd want is for a device driver to try to decide whether
it should talk to a printer using an LL address or a routable address. 
the device driver should not be trying to guess network policy any more
the device it wants to talk to.  nor should we presume that a device
driver is necessary.  

(I can talk to most of the printers around here without any
kind of device driver - since they all speak lpd and postscript.
I just type "port-lpr -Plp -Sprinter-address filename". )

---

From: Alex Karahalios <[email-masked]>
Date: Wed, 22 Jan 2003 14:22:25 -0700

Hi Rod,

What is wrong with a "device" acquiring both a v4LL address and an 
address via DHCP? By "device" I mean something that has a controlled 
set of applications which know how to handle both addresses. This makes 
the implementation much easier since the network stack or application 
does not have to deal with the LL address no longer being valid when a 
DHCP address is acquired.

The v4LL draft should not preclude both being active at any given time, 
although the draft may specify a mechanism such as the alternate (e.g. 
DHCP) acquisition of an address as a means to optionally disable v4LL.

Alex Karahalios

On Wednesday, January 22, 2003, at 01:34  PM, Rod wrote:

> STILL be easily able to communicate with IPv4LL addresses by the way 
> of ARP, which is NOT complicated, in fact that's how Mac OS X 10.2 
> does it today?

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 22 Jan 2003 13:48:36 -0800

> see if it helps to rephrase what I'm saying:

My apologies. Let me try to clarify.

> autoconfiguring devices will continue to function)

My opinion on this is that networks don't need a way to say this. I 
don't even really understand what it means for a network to say 
anything. A network is a collection of devices connected together, 
there is no central authority.

I do believe that IPv4LL address can cause some issues and a global 
address is preferable over an IPv4LL. I think that there is no reason 
to assign a link local address unless a device is unable to acquire a 
global address through any configuration method. As an example, if a 
client is configured to use DHCP and it receives no DHCP response, I 
believe it makes sense to try and assign an IPv4LL address.

> but we should at least be aware of it.

I think of IPv4LL as another configuration method, similar to DHCP, 
though you end up with a scoped address which does have limitations. I 
think it makes sense for vendors to offer an option to use only IPv4LL 
in addition to the other configuration methods they support. As stated 
above, I believe that if a configuration method fails to acquire an 
address, a device should try to self assign an IPv4LL.

> question of which is worse:

I don't see what adding any options to DHCP buys us. If a device gets a 
DHCP response, then presumably it's getting a global address so it 
doesn't need an address. If a device doesn't receive a DHCP response, 
then the device should self assign an IPv4LL. If the device is not 
configured to use DHCP then DHCP options won't matter. In the scenario 
you outlined before, it sounds like the only good solution is for your 
printer to be assigned to not bother with DHCP and just self assign an 
IPv4LL address.

> b. Failure of home networks that use such DSL modems in the presence of

Even in a managed environment, it may be desirable or acceptable for a 
device to self assign an IPv4LL initially. If you get a printer out of 
the box and it defaults to using IPv4LL (or DHCP and falls back to 
IPv4LL), it might be nice to have that printer just show up so you can 
connect to and configure it the way you'd like.

> standard for the managed network to fix the problem.

I still don't see a case for the "disable LL" signal. If you don't want 
IPv4LL addresses on your network, configure devices to use DHCP and 
don't let your DHCP server go down.

> minimizing harm to existing uses of that interface.

We are doing two things.

1) Introducing addresses that have a very limited scope. Those 
addresses can cause problems for applications that use referrals.

2) Introducing a method to assign an address to an interface. This 
method will only assign address which have a limited scope. Ideally, 
other methods would be used when available to acquire an address that 
does not have scope limitations.

There is no protocol on the wire that prevents people from manually 
assigning addresses. Why should there be one that prevents the computer 
from self assigning an IPv4LL address? Yes, IPv4LL addresses are 
arguably less functional that a global address, but if a global address 
is not available, they're a lot better than nothing.

-josh

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 16:50:21 -0500

> Whether that's "manual" or not, that's not an acceptable way to dictate

You have to do that anyway to manage them. You have to set up what stations
can manage them, who can manage them, etc. You think this stuff  happens by
magic some how? No. You *have* to do some manual config for managed devices.
Period.

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: Wed, 22 Jan 2003 16:52:57 -0500

> from a security point-of-view, it's exactly the same level of

No it's not, but you are unwilling to compromise from your "Perfect or
nothing" stance. 

Can anyone ELSE tell me if my manual idea has merit or not? Keith either
won't accept anything I say, or won't accept any idea not his own. I'm not
sure if I'm the first person to suggest manual configs here, but I doubt it.

I simpley think that it's usable NOW, requires no new magical config
protocol, and requires no changes to a spec. It simply requires the vendor
to implement some manual method of turning v4LL off.

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: Wed, 22 Jan 2003 16:54:33 -0500

> languages, without having to install drivers.

Um...it's also perfectly reasonable to expect that if you have a printer
that ships with three or four different network print protocols that you may
have to configure those, or turn them on or off.

As well, if your computer doesn't ship with the PPD files for that printer,
then it is perfectly reasonable to expect to have to install the PPD files
for that printer. This is common when a new printer is released after an OS
update.

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: Wed, 22 Jan 2003 16:57:13 -0500

> police those policies - it can filter traffic that doesn't follow them.

And who tells the network to do this...why, a *human*. Who decides network
policy? Why, a *human*. Who sets up userids and passwords? Why, a Human...

The network is nothing without humans telling it how to function. Your
objection here is really quite bizaare. My suggestion prevents NOTHING. It
allows you to turn stuff off. It allows vendors to implement that switch in
a way that makes sense for that device. It allows network managers to easily
set policy for that device.

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: Wed, 22 Jan 2003 17:09:16 -0500

On 01/22/2003 15:34, "Rod" <[email-masked]> wrote:

> Versions of Mac OS that support link-local will only acquire link local
> addresses when configured to use DHCP and the DHCP server does not respond.
> Various versions of the Mac OS will continue to send DHCP requests. If a DHCP
> server does appear, the Mac will use the address from the DHCP server but it
> will also continue to use the IPv4LL address. The IPv4LL address is maintained
> to avoid unnecessarily killing already established connections.

I have no problems with this.

> The Mac OS will watch for link changed events to determine if DHCP should be
> tried again or the IPv4LL address assignment should occur again.
>  

I do. I don't see a reason not to, unless there's a policy against it, such
as it will break an application, or the network ops folks don't want it.

> 
> On the other hand, if my machine or some other device for whatever reason
> can't get an address from DHCP, or if it doesn't implement DHCP, then I'd like
> it get an IPv4LL address. This assures me that I have some way of
> communicating with the device. I don't want my machine to silently refuse to
> acquire an address because some guy in the dorm playing a prank is sending out
> some magic packet to disable IPv4LL. I don't think we need to design a special
> protocol either. 

But, when you have DHCP present, then a prankster can keep you from getting
a v4LL address, simply by having a DHCP server up and running when you
connect an interface to the network. DHCP present, no v4LL address. But,
since it's a bogus DHCP server, you don't really have DHCP, now do you.

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

My proposal does neither. It simply removes the ability of
DHCP/BootP/whatever to deny a v4LL address automatically by it's presence on
the network prior to a computer getting a v4LL address.

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

But now, it's also impossible to easily disable LL completely. And there are
many cases where you want this. My proposal allows this too.

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

I never viewed it as a restriction per se, but rather quite sensible, and a
bit simpler, but it makes no real difference.

>  
> Do you realize no changes have to be made to the DHCP spec to support this?

Do you realize that if I have a rouge DHCP server, no v4LL machine that
supports not acquiring an address in the previous presence of DHCP can't?

I don't see this as a good thing. I want explicit human control over this.

> 
> Do you realize the presence of a DHCP server will NOT kill IPv4LL on the link?
> It will only make hosts that aquire a global address NOT acquire an IPv4 LL
> address as well (since they DON'T need it!), and STILL be easily able to
> communicate with IPv4LL addresses by the way of ARP, which is NOT complicated,
> in fact that's how Mac OS X 10.2 does it today?

You also have no control this way to say, hey, that's a bogus DHCP server.
You also assume, and I don't, that there is NO reason to get a v4LL address
if you use DHCP. 

> 
> You seem to think that DHCP will absolutely kill IPv4LL on the link. It will
> not! Not acquiring an IPv4LL address when you already have a global one does
> not mean you won't be able to communicate with devices that do have one,
> either because they only work with IPv4LL or because they failed to get a
> global address. If you are concerned with them getting global addresses, you
> can disable this yourself most of the time (either on the device itself or on
> the dhcp server) and instead they will use an IPv4LL address.

How? If I'm around a rouge DHCP/bootP server, then I have to set my machine
to manual config so as to avoid it. Now I have a manual address, so no v4LL
address, and no way to get one either.

> 
> I think this proposal goes in line with what you want, you just haven't taken
> the time to understand it well, and seem to be confusing it with earlier
> proposals of completely disabling IPv4LL with a dhcp option and whatnot. This
> is not the same. Your manual config suggestion seems unwarranted since I think
> if you understand these points you will see they cover the needs you have been
> addressing. 

No they don't. The mere presence of a functional BootP or DHCP server should
not be enough to kill v4LL addressing. There has to be more human control
over this.

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: Wed, 22 Jan 2003 17:11:08 -0500

> local route). I am assuming that we talk about the former.

I tend to prefer the simpler answer, mostly because it works better. Off
means no v4LL period, end of sentence. That way, if I, as a network manager,
choose to turn off v4LL, I have a simple way to completely disable it, but a
way that I can make harder for unauthorized people to manipulate.

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: Wed, 22 Jan 2003 17:13:13 -0500

> and if by "manual" you mean "cannot be automated" then it doesn't solve

That most certainly is NOT what *I* have meant at all.
 
> the device it wants to talk to.  nor should we presume that a device

The first part I agree with. As far as the necessity of a device driver,
well, that's always a *maybe*, so you can't really plan anything around it.

> I just type "port-lpr -Plp -Sprinter-address filename". )

Um...okay, so in the non-geek world, NO one is going to use that to print.

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: Wed, 22 Jan 2003 17:19:13 -0500

> there is no central authority.

Um...that last sentence is SO incorrect in SO many cases. You can't assume
all networks are ad hoc. All the ones I've ever done work on outside of my
house have a *very* central authority.

> believe it makes sense to try and assign an IPv4LL address.

But you cannot assume that there is NO need for both addresses, or that
there never WILL be a need. The better option is to make both possible.

> address, a device should try to self assign an IPv4LL.

What do you do about rouge DHCP servers?

> printer to be assigned to not bother with DHCP and just self assign an

Because not all DHCP servers are the ones you are supposed to use.

> don't let your DHCP server go down.

Um...I like the idea of being able to disable v4LL totally. So do a lot of
people in the right setup. I don't like the mere presence of a functional
DHCP server affecting v4LL addressing.

> is not available, they're a lot better than nothing.

I agree, but I also agree with keith that DHCP alone should not be enough to
stop v4LL address acquistion.

john

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

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 22 Jan 2003 23:03:18 -0000

> What do you do about rouge DHCP servers?

I always paint mine bleu.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 18:07:41 -0500

> there is no central authority.

Networks are resources in their own right.  They cost money and whoever
pays for them wants some say in how they are run. They are sometimes
seen as security threats. They fail. They require configuration and
management. Many of them have usage policies, and means of enforcing
those policies.

Now it is also the case that there are networks for which many of the
above characteristics do not apply.  Such networks may become more
prevalent in the future.  But we expect the same devices to play well in
both kind of networks.

> > 2. Having autoconfiguring devices try DHCP first will not
> > interoperate well with certain DSL modems.   Maybe that's not this
> > group's problem, but we should at least be aware of it.
> 

Even if this causes networks using DSL modems to break?  Are you
unconcerned about the interoperability issues with these networks?

> > Partially because of #2, it might be that an explicit indication
> > from DHCP(or some other protocol) that means "don't use LL" would be
> > better than interpreting a DHCP response to an address request as an
> > implicit indication that LL should not be used.  Or not.  I see this
> > as a question of which is worse:
> 
> I don't see what adding any options to DHCP buys us.

Again, it doesn't have to be DHCP.  And actually if the autoconfiguring
printer asks for an address from the DSL modem before the user's
computer, it's going to cause the user's computer to fail to connect to
the Internet whether or not the autoconfiguring printer looks at a
specific DHCP option or just uses the fact that it was assigned an
address.

So maybe we just don't worry about the DSL modems.  Or maybe we use
something besides DHCP.

> If a device gets
> a DHCP response, then presumably it's getting a global address so it 

But how does the printer know to not bother with DHCP?   It's supposed
to be autoconfiguring.  It doesn't necessarily have a manual override. 
Even if it does, the user doesn't know that it's needed, or how to use
it when it is needed.

> connect to and configure it the way you'd like.

Well if you have to configure the printer in order to make it work in
common cases, it doesn't seem like "zero configuration" any more.

> assigning addresses. Why should there be one that prevents the
> computer from self assigning an IPv4LL address? 

Neither is there any protocol that prevents hosts from choosing an
address at random from the 2**32 that are available.  But we would not
consider this a desirable behavior.  

We need to stop thinking of this as "preventing" a host from doing
something that isn't desirable - we can't stop hosts and implementors
from doing bad things anyway.  What we need to do is define how a host 
interacts with a network (where "network" can be dumb or smart, passive
or active, ad hoc or managed, isolated or connected) in order for that
host to understand how best to interact on that network.

We've been discussing whether it is wise for a host to assume that being
assigned a DHCP address is a good indication that it should not, by
default, configure a v4LL address.  I identified an apparently
common case where this will cause a failure.  Perhaps that is an
acceptable failure, though I am doubtful.  But if it's not acceptable
then we should perhaps consider other mechanisms for allowing a network
to tell a host to use some other kind of address besides v4LL -
especially given the occasional complaints that expecting low-cost
fixed-function devices to implement DHCP is too onerous.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 18:14:15 -0500

> > nework devices if you have to arrange for each device to be hooked
> > to a link that is shared with a computer that is doing the
> > configuration. Whether that's "manual" or not, that's not an
> > acceptable way to dictate policy.
> 
> You have to do that anyway to manage them. You have to set up what
> stations can manage them, who can manage them, etc. You think this
> stuff  happens by magic some how? No. You *have* to do some manual
> config for managed devices. Period.

To some degree, it depends on what the device does.   If the device is
just a temperature sensor, does it need access control?  Maybe, maybe
not.

Perhaps more to the point, if a user plugs an IP printer into a hub, the
user might want to specify who can print to that printer rather than
leaving it wide open for anyone who wants to consume the user's paper.
But should the network manager be required to explicitly specify policy
to that device? 

Just because the user wants to be able to specify some things does not
mean that the user should have to specify things that the device could
learn from the network.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 18:21:51 -0500

> And who tells the network to do this...why, a *human*. Who decides
> network policy? Why, a *human*. Who sets up userids and passwords?
> Why, a Human...

completely different scale.  it's one thing to set policy for plug-in
devices for large chunks of a network; quite another to have to
separately/individually configure each device.

> objection here is really quite bizaare. My suggestion prevents
> NOTHING. It allows you to turn stuff off. 

your situation make it so cumbersome to turn off LL that it's not a
feasible workaround for the problems that LL causes.

---

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

> just a temperature sensor, does it need access control?  Maybe, maybe

Maybe...but then again, if you have that much of an IP stack, then you have
a way to get data *out* of the device. If you can get data out, then you
have a way to get data in.

> But should the network manager be required to explicitly specify policy

By default, printers are open to everyone. If you want to change that, it's
manual. By default, under my proposal, you have v4LL addressing. You
normally, (for every printer I've ever configured, and that list is very
long), it ships with a default address, or a control panel on the printer,
or both. If it uses v4LL for the default, and you DON'T want that, or you
want additional config modes, then you use that to access the printer, (I
guarantee when you take the printer out of the box, and set it up, you will
be in the same room with it.) and make any other changes you'll need to
make, including either setting policy, or pointing it to a policy server,
etc.

> mean that the user should have to specify things that the device could

I'm not requiring that by default. ALL I am saying is that to *disable*
v4LL, you have to do that manually, not simply because there is a DHCP
server on the network. I'm not killing anything by default.

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 18:45:46 -0500

> > To some degree, it depends on what the device does.   If the device
> > is just a temperature sensor, does it need access control?  Maybe,
> > maybe not.
> 
> Maybe...but then again, if you have that much of an IP stack, then you
> have a way to get data *out* of the device. If you can get data out,
> then you have a way to get data in.

you don't necessarily have stable storage.

> > Perhaps more to the point, if a user plugs an IP printer into a hub,
> > the user might want to specify who can print to that printer rather
> > than leaving it wide open for anyone who wants to consume the user's
> > paper. But should the network manager be required to explicitly
> > specify policy to that device? 
> 
>  By default, under my proposal, you have v4LL addressing.
> You normally, (for every printer I've ever configured, and that list
> is very long), it ships with a default address, or a control panel on
> the printer, or both. If it uses v4LL for the default, and you DON'T
> want that, or you want additional config modes, then you use that to
> access the printer, 

requiring anyone to explicitly configure every device is not an
acceptable way to disable LL.  I've already explained why this is the
case.

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 18:46:32 -0500

> separately/individually configure each device.

You have to do it anyway...have you actually spent large amounts of time as
a network admin? To get to the automation, you have to spend some manual
time

> feasible workaround for the problems that LL causes.

<sigh>

Okay...this is like So cumbersome...NOT

Here's a script that will, when used with a decent network admin tool on a
Mac, kill en0 on every mac that tool has control over, and you have an admin
password on. Just replace the password in quotes with a valid one. (this can
be made more secure in a number of ways, but here's the minimum effort)

Count the lines boys and girls:

property killen0 : "/sbin/ifconfig en0 down"

do shell script killen0 password "someadminpassword" with administrator
privileges

Ta-daa.

Stick a valid password in there, make the script an application so the code
is no longer plain text, and *two* lines, (if you use shell directly, you
don't need applescript), and it's only two because I'm a property freak, it
could be done in ONE line.

It's a lot of things, but to call it cumbersome is just silly.

john

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

---

From: Rod <[email-masked]>
Date: Wed, 22 Jan 2003 17:48:59 -0600

> as it will break an application, or the network ops folks don't want 

Some people here have mentioned reasons not to, so the aforementioned 
method was suggested to apeace them. Can you elaborate on reasons to 
acquire an IPv4LL address when you already have a valid global one?

>> reason

But you can still communicate with devices that have IPv4LL addresses 
via ARP, so what seems to be the problem? See below.

>> preferred

It's not denying anything. The device will just rather get a global 
address because it can use that to communicate with anyone, LL or not. 
The only problem you have pointed out with this is the existence of 
bogus dhcp servers.

>> communicating

And you had been arguing fiercely all this time against a way to 
disable LL completely. Now that they give it to you you want the 
opposite?

>> was to

It makes a difference because devices don't need an IPv4LL address to 
communicate with other devices that use IPv4LL addresses exclusively or 
non-exclusively.

> supports not acquiring an address in the previous presence of DHCP 

But it can still communicate with IPv4LL devices.

>> the link?

Can you please elaborate on reasons why both addresses would be needed.

> address, and no way to get one either.

Although I agree with the proposal of not acquiring an IPv4LL address 
when a global address has already been acquired, I don't think devices 
that implement LL should be forced to implement DHCP. In the same way, 
I don't think the only way of acquiring an IPv4LL address should be to 
configure the device to use DHCP and then failing to acquire an address.

> not be enough to kill v4LL addressing. There has to be more human 

It's not killing v4LL addressing. The host is just using the address it 
finds more convenient to use.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 19:02:18 -0500

> > completely different scale.  it's one thing to set policy for
> > plug-in devices for large chunks of a network; quite another to have
> > to separately/individually configure each device.
> > 
> 
> You have to do it anyway...

uh, no.  I assure you that our network admins don't do configuration of
individual devices.  

> Here's a script that will, 

wonderful.  now make it work for every device on the network, no
matter what kind of device it is, so that the network admin can set
policy.

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 19:06:17 -0500

> you don't necessarily have stable storage.

You have enough to tell it to use DHCP, you have enough for the IP stack.

> acceptable way to disable LL.  I've already explained why this is the

You have, but from the POV of someone with no experience in actually running
a network of any real size. I *do* have that experience, and what I have
suggested would cause no admin more than five seconds of work per zeroconf
device...if that long.

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: Wed, 22 Jan 2003 19:36:09 -0500

> uh, no.  I assure you that our network admins don't do configuration of

Um...if you think for three seconds that I am going to believe that a
Windows PC on your network goes directly from factory to User Desktop with
absolutely no human intervention on it other than to unpack it, I'm going to
tell you that I think you don't know what you're talking about, and I want
proof.

> matter what kind of device it is, so that the network admin can set

LOL...what's your management tool that you use for every single device on a
network no matter what kind of device, platform or operating system?

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: Wed, 22 Jan 2003 22:36:05 -0500

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

> DHCP comes close.

Okay...that's a network stack configuration tool...i'm talking Network
management, ala Tivoli, CA - Unicenter, netOctopus...a bit more extensive.
Network admins need to do a lot more than just configure IP addresses.

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 23:03:19 -0500

> >> LOL...what's your management tool that you use for every single device on
> >a> network no matter what kind of device, platform or operating system?
> > 
> > DHCP comes close.
> 

well, we were talking about just the one bit that says whether to use LL or
not. to me it makes more sense for that bit be conveyed by DHCP than by a 
more complex and less standard mechanism.

and I don't particularly see why that bit needs to be any more authenticated
than any other address configuration information.  if DHCP is good enough for
address and netmask, it's good enough for LL yes/no.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 22:01:25 -0500

DHCP comes close.

Keith