Subject: Solving the wrong problems

From: Robert Elz <[email-masked]>
Date: Fri, 24 Jan 2003 22:00:43 +0700

There's been too much discussion on this list recently which
is ignoring the issues that actually matter, and concentrating
on chasing red herrings.

All of the stuff about what to do with rogue servers, malicious
nodes, and illicit network use is irrelevant.

Unless something being proposed actually makes one of those issues
worse than it would otherwise be, which no-one has been doing I
believe (leaving aside the question of whether having LL addresses
at all causes such problems).

That is, for example, the desire to have a way to disable LL addresses
isn't so that the network manager can make sure that no-one can use
the net without their permission, or similar, that's ludicrous, the
node(s) could just configure themselves with network 10 addresses,
or 192.168, or anything else (including addresses from the block that
are designated for use on the net in question).

The reason is because the net manager knows what will, and won't work
properly on their net, and can provide advice to the nodes as to what
they should do in order to work well in the local environment.

There's also no-one (sane anyway) around here pretending that any kind
of protocol message like this can override what the end user of the device
actually wants to do - that is, if you manually (however that's defined...)
configure the device to generate (or not) a LL address, then of course,
that is what it will do (I mean, no-one is suggesting that

	ifconfig interface LL-address

should fail, are they?)

I have yet to hear anyone explain why they would want (as a software
author, sending code into environments of which they have no knowledge
at all) to ignore the desires of the local network and simply do things
their own way.   If anything, the closest to this was the "because it
is simpler" argument, which would actually be a reasonable one if it
wasn't simply wrong.

So, can we all please ignore the "but I could if I wanted to simply
make my box do ..." type nonsense arguments as a justification for
"so I may as well do it automatically always" conclusion.   It is nonsense.

kre

---

From: Erik Guttman <[email-masked]>
Date: Fri, 24 Jan 2003 17:17:48 +0100

Let's decide this point once and for all then:

> their own way.  

Appletalk and NetBIOS still ship.  They work *in every LAN environment.*

Local networking with IP has not worked for consumers.  (By the way,
those are people who *cannot* set their IP address manually).  This
is because there are environments where

  - there is no DHCP, and no configured address
    (There is no disagreement here about how things should work.)

  - there is DHCP
    (There is some disagreement, but it looks like a rough WG consensus
     is emerging that when a host gets configuration with DHCP it will
     no longer use its own v4LL address.)

  - there is a DHCP server but it will not give the host an address
    (Here there is more disagreement.)

The question is:  Is it acceptable that a host which cannot get
an address from DHCP should then give up its IPv4LL configuration
and effectively shut down?  Is this a rare enough event that
consumer networking vendors will be satisfied that IP isn't
totally unreliable compared to Appletalk, etc?

Erik

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jan 2003 11:33:01 -0500

> and effectively shut down?  

I think the question is slightly different:

Is it acceptable that a host which is refused an address from DHCP
should not configure an IPv4LL address without explicit user
approval?

("refused an address" being different than "DHCP did not answer")

Keith

p.s. I mean, don't you want user approval anyway before you start
accepting packets from and sending packets to a strange network?

---

From: "Subrata Goswami" <[email-masked]>
Date: Fri, 24 Jan 2003 08:34:44 -0800

>Is it acceptable that a host which cannot 
> get an address from DHCP should then give up its IPv4LL 
> configuration and effectively shut down? 

Can you please clarify what you mean by this question ? Why are you
tying IPv4LL with DHCP ? I would think the following is a more
comprehensive list of scenerios.

1. DHCP Server Present, DHCP Client Present
	Client first tries Manual
	Then DHCP
	Then LL

2. DHCP Server Present, DHCP Client Absent
	Client first tries Manual
	Then LL
	
3. DHCP Server Absent, 	
	Client first tries Manual
	Then LL

Subrata

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Erik Guttman
> Sent: Friday, January 24, 2003 8:18 AM
> To: Robert Elz
> Cc: [email-masked]
> Subject: Re: Solving the wrong problems
> 
> 
> Robert Elz wrote:
> > There's been too much discussion on this list recently which is 
> > ignoring the issues that actually matter, and concentrating 
> on chasing 
> > red herrings.
> 
> > at all) to ignore the desires of the local network and simply do 
> > things their own way.
> 
> Local networking with IP has not worked for consumers.  (By 
> the way, those are people who *cannot* set their IP address 
> manually).  This is because there are environments where
> 
> The question is:  Is it acceptable that a host which cannot 
> get an address from DHCP should then give up its IPv4LL 
> configuration and effectively shut down?  Is this a rare 
> enough event that consumer networking vendors will be 
> satisfied that IP isn't totally unreliable compared to Appletalk, etc?
> 
> Erik
>

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 24 Jan 2003 12:02:59 -0500

> totally unreliable compared to Appletalk, etc?

No.

I can explain why, but I think every POV is well understood by now.

john

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

---

From: Erik Guttman <[email-masked]>
Date: Fri, 24 Jan 2003 18:41:20 +0100

> comprehensive list of scenerios.

We agree that if the client gets an address somehow (DHCP, manual
configuration, whatever) it will use it.

What we are not agreement about is the behavior of the host which
cannot get address configuration except through the use of IPv4LL.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Fri, 24 Jan 2003 18:49:12 +0100

> ("refused an address" being different than "DHCP did not answer")

DHCPNAK is the way that DHCP can respond to refuse a client an address,
right?  This could mean the DHCP server has no more addresses to give
out.  Or it could mean the administrator doesn't know the requester's
mac address and doesn't want to give out a routable IP address.  Or it
could mean something else.

Erik

---

From: "s. goswami" <[email-masked]>
Date: Fri, 24 Jan 2003 13:14:32 -0500 (EST)

Here is the table again. You are talking about a situation
similar to 3 below, as far as the host is concerned  DHCP
server does not exist when the host does not reply back
for its DHCP Request.

1. DHCP Server, DHCP Client
	Try Manual, if no address
	Try DHCP, if no address
	Try LL
2. DHCP Server, No DHCP Client
        Try Manual
        Try LL
3. No DHCP Sever
        Try Manual
        Try LL

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jan 2003 13:38:04 -0500

> DHCPNAK is the way that DHCP can respond to refuse a client an
> address, right?  This could mean the DHCP server has no more addresses
> to give out.  Or it could mean the administrator doesn't know the
> requester's mac address and doesn't want to give out a routable IP
> address.  Or it could mean something else.

Right.  And I think this is part of the problem:

Sysadmins are currently overloading DHCP to do something it wasn't
really designed to do, but it largely works for them.  The introduction
of LL to IPv4 adds a new state that wasn't anticipated by this use of
DHCP. The host's choice is no longer"connect" vs."don't connect"; it's
"connect" vs."don't connect" vs."you can't have a routable address but
you can use LL".  Right now "don't connect" and "you can't have a
routable address" essentially mean the same thing (in that they produce
the same behavior at the host); what is missing is an indication of
whether it's okay for the host to automatically configure LL if it is
not given a routable address.

(We could argue about the default in the absence of an indication one
way of the other.  But I think I'm satisfied with either default, as
long as such an indication can be made and respecting a definite "don't
automatically configure LL" indication is required as part of the LL
standard.).

Now, I think most network admins would make their lives much easier by
giving a routable address to every authorized host and telling the rest
to not use LL.  But I am not confident enough that this is a good idea
for everyone to argue that networks shouldn't be able to allow LL
addresses if they want to.  Having a definite indication of "LL is okay"
vs. "LL is not okay" seems like a good compromise.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Jan 2003 10:42:54 -0800

> could mean something else.

DHCPNAK is only a valid response to DHCPREQUEST, and DHCPREQUEST is 
only a valid response to DHCPOFFER, which offers an IP address.   So 
no, you can't use DHCPNAK to say "sorry, I'm not giving you an address."

---

From: "s. goswami" <[email-masked]>
Date: Fri, 24 Jan 2003 14:01:07 -0500 (EST)

The sequence of messages are as follows.

DHCP Client			DHCP Server

	1. DHCPDISCOVER (broadcast) ->
	2. DHCOOFFER   (multiple)   <-
	3. DHCPREQUEST 		    ->
	4. DHCPACK/NACK		    <-

What happens if 2 is not received by the client ?
How often does the client do DHCPDISCOVER ?
When does the client host give up on DHCP ?
Does the host do DHCPDISCOVER after it has confiured LL ?
What happens when a DHCP server is deployed in an existing LL net?
What happens to LL capable host when a DHCP server goes down and comes up?
.
.

Subrata

---

From: Daniel Senie <[email-masked]>
Date: Fri, 24 Jan 2003 16:00:17 -0500

>could mean something else.

It could be you're sitting on a park bench, trying to use LL to sync your 
laptop with your PDA, and you don't give a damn if there's a public access 
point present or not, you intend to use 802.11b to talk between your laptop 
and your PDA. Do you really want the administrator of an ad-hoc public 
access point, provided out of someone's apartment window, dictating how 
your laptop and PDA talk to one another?

This is, I think, the kind of question to ask when contemplating whether a 
DHCP server should have ANY standing to tell a client what to do, if that 
client is not granted an address.

---

From: "s. goswami" <[email-masked]>
Date: Fri, 24 Jan 2003 16:44:08 -0500 (EST)

Great point

---

From: Ralph Droms <[email-masked]>
Date: Fri, 24 Jan 2003 22:03:55 -0500

DHCPNAK generally means that the DHCP server can't fulfill the
specific request that the client sent.  For example (from RFC2131,
section 3.1, Client-server interaction - allocating a network
address):

      If the selected server is unable to satisfy the DHCPREQUEST message
      (e.g., the requested network address has been allocated), the
      server SHOULD respond with a DHCPNAK message.

The context is that the server has sent an address to the client in
a DHCPOFFER, but the server cannot satisfy the request for that
address in the subsequent DHCPREQUEST from the client.

DHCPNAK can also be sent to indicate to a host that it has moved
to a new link and its previously assigned address is no longer valid.

DHCPNAK is not used to indicate to the client that the client will
not be assigned an address and that the client should not
send any more DHCP messages.  A server that is unwilling to assign
an address simply ignores the messages from the client.

DHCPNAK used in the way I described in the first sentence of the
previous paragraph could also be used in a DOS attack, I suppose...

- Ralph

---

From: Robert Elz <[email-masked]>
Date: Sat, 25 Jan 2003 18:45:13 +0700

Date:        Fri, 24 Jan 2003 16:00:17 -0500
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | Do you really want the administrator of an ad-hoc public 
  | access point, provided out of someone's apartment window, dictating how 
  | your laptop and PDA talk to one another?

If I'm going to be using their access point, then yes, of course.

If they're also providing a DHCP server, current clients will just use
that to configure the addresses they will use, won't they?   What's the
difference?   How can this possibly be stopped?

The correct solution, in that situation is not to use the access point.

From a private message you sent me, I think that most of your concern is
based around the practice of current wireless implementations attempting to
be super-automatic, and not tell the user anything about what AP they're
actually using, and not allow the user to control that choice.

If I'm planning to set up an ad-hoc net on a park bench, then I really
want to be in ad-hoc mode, not using anyone else's AP just because it
happens to be there, and one of the most minor reasons for this is
because they might just happen to tell my node  that it isn't allowed
a LL address (in fact, if they were to do that, and it stopped my node
from functioning, I'd thank them, as they'd be preventing me from
sending my packets much further than they would otherwise have gone,
or I intended them to travel).

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 25 Jan 2003 18:04:47 +0700

Date:        Fri, 24 Jan 2003 17:17:48 +0100
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <[email-masked]>

  | Local networking with IP has not worked for consumers.  (By the way,
  | those are people who *cannot* set their IP address manually).

Yes, I know, and I fully agree with providing a solution to that.

  | This is because there are environments where
  | 
  |   - there is no DHCP, and no configured address
  |     (There is no disagreement here about how things should work.)

agreed.

  |   - there is DHCP
  |     (There is some disagreement, but it looks like a rough WG consensus
  |      is emerging that when a host gets configuration with DHCP it will
  |      no longer use its own v4LL address.)

agreed.

  |   - there is a DHCP server but it will not give the host an address
  |     (Here there is more disagreement.)

Yes.

  | The question is:  Is it acceptable that a host which cannot get
  | an address from DHCP should then give up its IPv4LL configuration
  | and effectively shut down?

Yes, in the case that you can distinguish this from the first case above.

Take one possible example.   You have a device whose (non-network)
interface to the world is a power cord, that can be plugged and unplugged,
and a LED (imagine what states you can for how it can use this to indicate
"all OK" "no network connected" "no power" ...)

Now let that device be connected to a link which has a DHCP server (so
we're not in case 1 above) but no address is assigned (which I believe
means that 2563 or perhaps a replacement of that, or similar, is in use,
otherwise it is indistinguishable from case 1).

The DHCP server says "no LL address" because it knows the device has been
plugged into a LAN where there are no other devices at all (perhaps this
is one of those "unregistered MAC address -> purgatory VLAN type switches
configured to put unknown devices on a VLAN that nothing else will be
automatically connected to - but to which there is a router, with its
dhcp relay etc).

Now, if the device just goes and configures itself a LL address, and starts
flashing its LED in the "all is functioning" state (just the same as it would
if it connected to a net with no DHCP server at all) then how is the
user, who is now attempting to contact the device (using mDNS or SLP or
something, doesn't matter what here, to find it) to know that they're
wasting their time?

Isn't it much better for the device to simply disable itself, and flash
its "no network" LED pattern, and by doing so, inform the user that there's
something wrong with the network connection, so the user can start looking
for the correct problem source (pretty much the same way it would do if
LL addresses had never been invented, and it was unable to get an address
using DHCP) ?

What seems to be the problem is that people are imagining that the people
who configure DHCP servers are evil bastards, deliverately setting out to
do everything in their power to prevent the network from being used.   While
there may be a few like that around (and remember that they same people
usually also get to configure the switches, etc, so have other ways of
denying you access if they want), most DHCP people are trying to make the
network function, not misfunction.   If they are going to deny you what
Keith calls a "routable" address, and tell you not to use a LL address either,
there's almost certainly a very good reason for that.

  | Is this a rare enough event that
  | consumer networking vendors will be satisfied that IP isn't
  | totally unreliable compared to Appletalk, etc?

I agree that it is going to be very rare.   But I think it will provide
the (truly dumb) devices functionality that appletalk (etc) cannot - an
appletalk device in the situation above would simply configure itself an
appletalk address and sit waiting for someone to talk to it, believing
that the other device(s) are just being slow to be connected.

Of course, in all of this, for devices that aren't quite so dumb, there's
always the option for a user to explicitly tell the device to override the
DHCP option, and go ahead and make a LL address anyway.  But this should
only happen via explicit user action (perhaps pressing an unbent paper
clip into a little hole to depress a switch, or something, for devices
with truly primitive user interfaces.

kre

---

From: Daniel Senie <[email-masked]>
Date: Sat, 25 Jan 2003 10:50:33 -0500

>or I intended them to travel).

While this is indeed obvious, my hope in sending the note to the list was 
NOT to focus on the particular weaknesses of 802.11b and many 
implementations, or the cluelessness of some of its users, but rather to 
point out the real possibility that someone could cause users harm.

Regardless, there's another case with 802.11b in public hot spots that's 
arguably worse in terms of having a DHCP command to "get the hell off the 
network":

You go to a Starbucks and plan to use the T-Mobile hotspot. In my backpack, 
I place an AP of my own, using the same SSID, and a laptop acting as DHCP 
server, sending out a "get off the network" DHCP response to anyone trying 
to get on the 'net. My AP can match the SSID and Mac address of the hot 
spot AP, and the DHCP server can spoof its identity to match the router 
connecting the hotspot to the outside world.

The point is the ability to send a message to someone's station to NOT do 
something can and is nasty.

It was also a bad idea in 802.5 token ring. It was entirely possible to set 
up a station that'd listen for others to come on a token ring, and send 
them a "get off the ring" message. Stations were required to comply with 
such messages. Of course there was no authentication.

In the name of giving administrators control, bad and dangerous mechanisms 
can be created.

---

From: "Subrata Goswami" <[email-masked]>
Date: Sat, 25 Jan 2003 08:41:42 -0800

The way Erik  is  wording the 3 cases implicitly requires that
every LL device MUST have a DHCP client.

The onus of deciding whether to use LL or DHCP is placed mostly on the 
device, which in most cases would be very resource limited 
(not exactly a big bulky server with 4 processor and 2 giga byte of 
RAM). This I think would makes sure that LL would not be 
applicable in many situations where it could have played a big part.

I my view, DHCP should have NO SAY on where and how a device should
use LL. It is better to decouple the two protocols.

Subrata

---

From: "Subrata Goswami" <[email-masked]>
Date: Sat, 25 Jan 2003 08:41:42 -0800

See inline

> [mailto:[email-masked]] On Behalf Of Robert Elz
> Sent: Saturday, January 25, 2003 3:05 AM
> To: Erik Guttman
> Cc: [email-masked]

Actually, it has to be specified how the device figures out that 
there is a DHCP server.  

> Yes, in the case that you can distinguish this from the first 

Not really, if the DHCP server does not send out any DHCPOFFER then the
device would not know if there is a DHCP server or not.

> interface to the world is a power cord, that can be plugged 
> and unplugged, and a LED (imagine what states you can for how 
> it can use this to indicate "all OK" "no network connected" 
> "no power" ...)
> 

what happens if the device does not even have an LED, or the LED
malfucntions ?

> Now let that device be connected to a link which has a DHCP 
> server (so we're not in case 1 above) but no address is 
> assigned (which I believe means that 2563 or perhaps a 
> replacement of that, or similar, is in use, otherwise it is 
> indistinguishable from case 1).
> 

again, how does the device distinguish if there is no DHCPOFFER ?

> The DHCP server says "no LL address" because it knows the 
> device has been plugged into a LAN where there are no other 
> devices at all (perhaps this is one of those "unregistered 
> MAC address -> purgatory VLAN type switches configured to put 
> unknown devices on a VLAN that nothing else will be 
> automatically connected to - but to which there is a router, 
> with its dhcp relay etc).
> 

what happnes if the device received two DHCPOFFERS from two
different DHCP servers, one saying can use LL and the other saying
do not use LL. 

> Now, if the device just goes and configures itself a LL 
> address, and starts flashing its LED in the "all is 
> functioning" state (just the same as it would if it connected 
> to a net with no DHCP server at all) then how is the user, 
> who is now attempting to contact the device (using mDNS or 
> SLP or something, doesn't matter what here, to find it) to 
> know that they're wasting their time?
> 

I do not see any problem here. The device would not have a corresponding
entry in SLP or mDNS, and the user can easily figure that out from
the absence of the entry.

> Isn't it much better for the device to simply disable itself, 
> and flash its "no network" LED pattern, and by doing so, 
> inform the user that there's something wrong with the network 
> connection, so the user can start looking for the correct 
> problem source (pretty much the same way it would do if LL 
> addresses had never been invented, and it was unable to get 
> an address using DHCP) ?
> 

No, not all devices that would use LL would have blinking LED's. 

> What seems to be the problem is that people are imagining 
> that the people who configure DHCP servers are evil bastards, 
> deliverately setting out to
> there may be a few like that around (and remember that they 
> same people usually also get to configure the switches, etc, 
> so have other ways of denying you access if they want), most 
> DHCP people are trying to make the
> Keith calls a "routable" address, and tell you not to use a 
> LL address either, there's almost certainly a very good 
> reason for that.
> 

DHCP has its limitations.

> the (truly dumb) devices functionality that appletalk (etc) 
> cannot - an appletalk device in the situation above would 
> simply configure itself an appletalk address and sit waiting 
> for someone to talk to it, believing that the other device(s) 
> are just being slow to be connected.
> 
> Of course, in all of this, for devices that aren't quite so 
> dumb, there's always the option for a user to explicitly tell 
> the device to override the DHCP option, and go ahead and make 
> a LL address anyway.  But this should only happen via 
> explicit user action (perhaps pressing an unbent paper clip 
> into a little hole to depress a switch, or something, for 
> devices with truly primitive user interfaces.
> 

what happens if you paper clip is confiscated at the airport ?

> kre

The way you are wording the 3 cases above implicity requires that
every LL device MUST have a DHCP client.

I my view, DHCP should have NO SAY on where and how a device should
use LL. It is better to decouple the two prorocols.

---

From: Alex Karahalios <[email-masked]>
Date: Sat, 25 Jan 2003 11:03:41 -0700

Hi Subrata,

I agree that DHCP and LL should be orthogonal. Given that, a device 
could poses both DHCP and LL addresses at a given time.

As far as RFC2563 pertains to this, I suppose that a device could have 
a configuration option which would tell if it were to honor the DHCP 
auto-config option. This in my view is no different then a device 
deciding if it should use a manual IP address rather than one assigned 
by a DHCP server - which is the way most computer OSes currently behave.

Alex Karahalios

---

From: "Philip Nye" <[email-masked]>
Date: Sat, 25 Jan 2003 18:10:06 -0000

> From: "Ted Lemon" <[email-masked]>
>

RFC2563 effectively does three things:

1. It says that the DHCP server can offer Address=0.0.0.0 as a way of saying
"you can't have an address"

2. It defines a boolean option which says "OK to autoconfigure a LL address"
or "Don't autoconfigure"

3. It defines some rules about which combinations of the above two must be
supported in which circumstances and by which devices. We could probably
change/supercede these rules if it suited us.

It is therefore clear that using this RFC the DHCP server _could_ dictate
ANY of the four possible combinations of DHCP-assigned and v4LL addresses:

DHCP v4LL
 No   No
 No   Yes
 Yes  No
 yes  yes

So rather than arguing about what DHCP can or can't do we should consider
the much harder question of what we think it is appropriate for it to do in
the LL context.

Most of this hinges on whether it is legitimate for the DHCP server to say
"No, No":

A. Is the DHCP server the all powerful dictator? or
B. Does the individual have complete autonomy? or
C. Is there some in between state - and if so how is it defined?

RFC2563 is clearly aimed at A. If we want B then there seems little point in
supporting a RFC2563 style option at all since getting anything except a
valid address from the server is equivalent to getting no answer.

The only possibility for C that I have seen is a manual override. Are there
any other suggestions?

Philip

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 25 Jan 2003 14:06:36 -0500

> what happens if the device does not even have an LED, or the LED

Even if it has one, it does you no good if it's in a different room. For
devices like that, you'd only use the LED as a backup in case the network
connection was malfunctioning.

For example, I just usually chuck base stations in a suspended ceiling. They
work just fine, but are out of the way. The LED's of course, are useless.

john

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

---

From: "Subrata Goswami" <[email-masked]>
Date: Sat, 25 Jan 2003 12:11:30 -0800

see inline

> Sent: Saturday, January 25, 2003 3:45 AM
> To: Daniel Senie
> Cc: [email-masked]
> >From a private message you sent me, I think that most of 
> your concern 
> >is
> based around the practice of current wireless implementations 
> attempting to be super-automatic, and not tell the user 
> anything about what AP they're actually using, and not allow 
> the user to control that choice.
> 
> If I'm planning to set up an ad-hoc net on a park bench, then 
> I really want to be in ad-hoc mode, not using anyone else's 
> AP just because it happens to be there, and one of the most 
> minor reasons for this is because they might just happen to 
> tell my node  that it isn't allowed a LL address (in fact, if 
> they were to do that, and it stopped my node from 
> functioning, I'd thank them, as they'd be preventing me from 
> sending my packets much further than they would otherwise 
> have gone, or I intended them to travel).
> 

I think I would prefer a working service, rather than being told
that I can not use my device because someone nearby is encroaching
into the park's property.

---

From: Robert Elz <[email-masked]>
Date: Sun, 26 Jan 2003 15:02:44 +0700

Date:        Sat, 25 Jan 2003 10:50:33 -0500
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | The point is the ability to send a message to someone's station to NOT do 
  | something can and is nasty.

My point was that the ability to do that exists already.   Nothing is
being added that cannot already be done.   The sole difference is that
a defined (easy to detect) way to achieve results that can already be
achieved is being offered.

  | In the name of giving administrators control, bad and dangerous mechanisms 
  | can be created.  

Of course.   But they're going to take control one way or another anyway.
You can't prevent that (other than by not using their network).   Isn't
it better to have an obvious "the admin says you can't (or shouldn't) do
that" technique, than just "it failed" ?

kre

---

From: Robert Elz <[email-masked]>
Date: Sun, 26 Jan 2003 15:14:03 +0700

Date:        Sat, 25 Jan 2003 08:41:42 -0800
    From:        "Subrata Goswami" <[email-masked]>
    Message-ID:  <000401c2c490$a50220b0$c900a8c0@SGOSWAMIPCL>

  | Actually, it has to be specified how the device figures out that 
  | there is a DHCP server. 

It gets a DHCP reply.    That is obvious.   The only DHCP reply it
can get is a DHCPOFFER.   So, it gets one of those.   If it doesn't,
it can assume there's no DHCP server.

  | Not really, if the DHCP server does not send out any DHCPOFFER then the
  | device would not know if there is a DHCP server or not.

Exactly, so we are assuming that it does get a DHCPOFFER.

  | what happens if the device does not even have an LED, or the LED
  | malfucntions ?

What happens if the power supply malfunctions?   Let's be reasonable
please, if manufacturers want to make devices where it is impossible
to work out what kind of problem might exist whenever they don't work
perfectly, then it is going to be impossible for anyone to ever work
out what is wrong (whether it is a "no address for you" or a broken
wire in the drop cable, or too far from base station, or not plugged
in properly, or ...)

  | what happnes if the device received two DHCPOFFERS from two
  | different DHCP servers, one saying can use LL and the other saying
  | do not use LL.

DHCP says that if you get 2 offers, you can pick whichever you like.
I see no reason at all to change that, so the client picks whichever
of those 2 it likes.   If one of them offers an address, most likely
it would pick that one (or one of them if both do).  If neither offers
an address, and one says "use LL" and the other says "no LL", then
I think if I was the client, I'd pick the "use LL" offer, and do it.

  | I do not see any problem here. The device would not have a corresponding
  | entry in SLP or mDNS, and the user can easily figure that out from
  | the absence of the entry.

But why does it appear to be missing?   Is it the server or the client
that isn't working properly?   Or the switch/hub/router that is between
them?   You have to start somewhere when debugging these problems,
and starting with "it doesn't work" and nothing more, rarely helps.

  | No, not all devices that would use LL would have blinking LED's. 

No, of course not, but any device rational to use (from toasters to
air-conditioners, to washing machines, to car alarms, to ...) has some
means of "I am working" user feedback.

  | DHCP has its limitations.

of course.   And no-one is pretending that a network has to use it, if
it is inappropriate.

  | The way you are wording the 3 cases above implicity requires that
  | every LL device MUST have a DHCP client.

Yes, that's something I would support - either a DHCP client or
expect to be manually configured.   Nothing else can possibly allow
the device to function on the internet.    And remember, it is
internet standards that the IETF makes.

  | The onus of deciding whether to use LL or DHCP is placed mostly on the 
  | device, which in most cases would be very resource limited

Supporting a DHCP client is one of the easiest things for a device
to manage, it takes just about no resources.   What are you imaging
this client actually doing with so few resources that it can't handle
that?

kre

---

From: Robert Elz <[email-masked]>
Date: Sun, 26 Jan 2003 15:22:54 +0700

Date:        Sat, 25 Jan 2003 12:11:30 -0800
    From:        "Subrata Goswami" <[email-masked]>
    Message-ID:  <001901c2c4ad$f394d980$c900a8c0@SGOSWAMIPCL>

  | I think I would prefer a working service, rather than being told
  | that I can not use my device because someone nearby is encroaching
  | into the park's property.

Of course, and you can have that, you just config your systems to
use their own private wireless LAN, and ignore what is coming from
other places (and do remember that you can't tell the difference
between a stranger nearby, and the local council/authority/... who
has jurisdiction for the park).

The point really is that if you're using someone else's LAN, then can
do whatever to you that they want to do, and there's no way at all
that you can prevent that - other than avoiding using their LAN.

If you somehow believe that just configuring a LL address (assuming
they allow to to work) will be a panacea, and then you get to use
whatever LAN you like for your private purposes, then you have a shock
coming when you actually try it.   And so you should have.

kre

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Jan 2003 07:49:36 -0800

> that" technique, than just "it failed" ?

Like many techniques that can be used to deny service, this one is 
great in theory.   The problem is that because it opens up an easy DoS 
attack, it's not great in practice.   I am not arguing that the 
administrator being able to send an affirmative message to the client 
to tell it that it can't use the network is a bad thing.  I am arguing 
that programming the client to obey such a message is a bad thing, not 
because some legitimate administrator will use it, but because some 
attacker will use it.   (I will admit that I do not believe that the 
administrator at an ISP is the legitimate administrator of my home 
network, of course).

After this weekend's fiasco, I think we can all dispense with the idea 
that nobody would do such a thing, so we don't need to worry about it.  
  Mechanisms that massively amplify a miscreant's ability to create 
havoc can't be left lying around where a miscreant can use them, or 
they will be used.

---

From: Robert Elz <[email-masked]>
Date: Mon, 27 Jan 2003 08:54:47 +0700

Date:        Sun, 26 Jan 2003 07:49:36 -0800
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | The problem is that because it opens up an easy DoS attack,

I am still waiting to learn what this is.   Absolutely nothing that has
been offered so far looks to me like "opening up" anything.

I believe you have even agreed that if an "attacker" can answer your
DHCPDISCOVER packets (one way or another) they can already wreak havoc
with your network (offer you useless IP addresses, etc).

What is really new in this new method?   In fact, even convince me that
the 2563 method is as bad as what exists already (given that to be effective
it requires that legitimate dhcpoffers be blocked, whereas other dhcp
attacks do not) and I'll rethink this (which does not necessarily mean
that I will arrive at a different conclusion).

  | I am arguing 
  | that programming the client to obey such a message is a bad thing, not 
  | because some legitimate administrator will use it, but because some 
  | attacker will use it.

For that argument to make sense, you'd have to also argue that clients
should not obey any dhcp reply, as not only can some legitimate administrator
use it, but also because some attacker will use it.

In fact, you'd have to require that a client not take any notice of any
autoconfiguration methods, as they necessarily can't be authenticated,
and hence are open to attacks.

In that case, it would be time for zeroconf to shut down wouldn't it?
Its whole aim is autoconf.

  | After this weekend's fiasco, I think we can all dispense with the idea 
  | that nobody would do such a thing, so we don't need to worry about it.

Of course they will.   On the other hand, we really can't allow the
possibility that "evil doers" will do their evil to prevent us from
doing what we need to operate, can we?   There needs to be a balance.
 
  |   Mechanisms that massively amplify a miscreant's ability to create 
  | havoc can't be left lying around where a miscreant can use them, or 
  | they will be used.

Of course.   But what has that got to do with the current topic?  What
is amplifying anything here?    You're assuming that, without, at least
so far, being able to demonstrate in any way at all that 2563 is even
as bad as DHCP itself in this regard.   Where's the amplification?

kre

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Jan 2003 19:57:39 -0800

> been offered so far looks to me like "opening up" anything.

I already explained to you why the RFC2563 attack is more effective 
than simply giving out a bogus IP address.  If you get a bogus IP 
address you can still do IPv4ll.   If you are attacked via RFC2563, and 
you honor the attack, you can't use the network at all.

---

From: Robert Elz <[email-masked]>
Date: Mon, 27 Jan 2003 11:38:45 +0700

Date:        Sun, 26 Jan 2003 19:57:39 -0800
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | I already explained to you why the RFC2563 attack is more effective 
  | than simply giving out a bogus IP address.  If you get a bogus IP 
  | address you can still do IPv4ll.

That isn't what current IPv4LL implementations do (note: "bogus" here
is immaterial, the host can't tell what is bogus and what isn't), and
isn't the position that this WG seems to be converging upon.

See the message from Erik Guttman, Fri 24 Jan (<[email-masked]>)

The issue being debated has been about whether there can be/should be
a mechanism to disable LL even in cases where the DHCP server doesn't
want to give out an address (which is why 2563 is relevant of course).

So, once again, what is this problem that 2563 causes and doesn't
already exist?

kre

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jan 2003 14:11:49 -0600

> isn't the position that this WG seems to be converging upon.

The current draft says that if you are IPv4ll aware, you can 
interoperate with IPv4ll clients on the local link even if you don't 
have an IPv4ll address yourself.   I agree that the draft needs to be 
reworded a bit, though - it should state this as the correct behavior, 
rather than making it optional.

> want to give out an address (which is why 2563 is relevant of course).

The issue some people were debating is whether or not there should be a 
mechanism for disabling IPv4ll.   The mechanism that is actually 
proposed in the draft, and that most people seem to agree is correct, 
is that if you get a routable address, you don't need to keep your 
IPv4ll address.   This is _not_ the same thing as disabling IPv4ll.

> So, once again, what is this problem that 2563 causes and doesn't

I think you're being deliberately obtuse here, Robert - you're not a 
dummy, and I have explained this twice already.   If you genuinely do 
not understand what the problem is, please contact me offline and I'll 
try to explain it to you.   If you don't agree that it's a problem, 
that's okay, but please specifically say that you don't agree that it's 
a problem, rather than using rhetorical tricks like this, so that we 
can just agree to disagree and stop wasting everybody's time.

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jan 2003 14:27:23 +0700

Date:        Mon, 27 Jan 2003 14:11:49 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | The current draft says that if you are IPv4ll aware, you can 
  | interoperate with IPv4ll clients on the local link even if you don't 
  | have an IPv4ll address yourself.

That's fine.

  | I agree that the draft needs to be 
  | reworded a bit, though - it should state this as the correct behavior, 
  | rather than making it optional.

Yes, there are several places where extra clarity would help.

  | The issue some people were debating is whether or not there should be a 
  | mechanism for disabling IPv4ll.   The mechanism that is actually 
  | proposed in the draft, and that most people seem to agree is correct, 
  | is that if you get a routable address, you don't need to keep your 
  | IPv4ll address.   This is _not_ the same thing as disabling IPv4ll.

It _is_ the same thing as I have been arguing for however.   As has been
explained on this list before, when we say "disable IPv4LL" what we (most
of us anyway) mean is "disable the algorithm by which a node acquires an
IPv4 LL address".   "Disable IPv4LL" is just a shorter way of saying that.

There has been some suggestion that nodes should also have a way to
disable communications with other nodes using LL addresses.   I agree
with that - but in the same context as nodes should have a way to
disable communication with any other random set of nodes, I don't see
anything so special about LL that it needs special treatment.
This one is also one I'd be hesitant about requiring anywhere, as it
is clearly one where the maker of the node is likely to know what its
requirements are likely to be, and because disabling communications can't
possibly be aiding interoperability.

With this clarification, do you still have the same problems?

  | I think you're being deliberately obtuse here, Robert - you're not a 
  | dummy, and I have explained this twice already.

No, you attempted to explain twice.  I responded twice showing why your
explanation was incorrect.   I know it is tempting to assume that if
any random node can send a packet which causes another node to shut down
(or fail to operate in some way) that that *must* be enabling a DoS attack.
But that isn't true, it only *enabled* a DoS attack if there isn't already
a way to accomplish the same thing (or perhaps if the other way is much
harder to execute).   While 2563 can certainly be used as a mechanism to
carry out a DoS attack, it does not enable one - it adds absolutely nothing
that doesn't exist already - more than that, it is a method much easier to
defeat than what already exists.

  | If you genuinely do 
  | not understand what the problem is, please contact me offline and I'll 
  | try to explain it to you.

Please explain it to everyone.

  | If you don't agree that it's a problem, 
  | that's okay, but please specifically say that you don't agree that it's 
  | a problem,

I have said that several times.   It isn't a problem.   Or not unless
you can show something that I am currently not seeing (and which no-one
else here seems to be seeing either, or I expect that someone else would
have sent a message re-wording yours, to make the point clearer).

  | rather than using rhetorical tricks like this, so that we 
  | can just agree to disagree and stop wasting everybody's time.

I didn't use rhetorical tricks, or I don't think I did.   I just asked you
to explain the problem that is new from 2563 - what is it that 2563 allows
that can't already be done (and I think, better, from a DoS attackers point
of view).

And just disagreeing isn't where this should stop - if there are security
problems, they need to be made abundantly clear, so we can make sure to
avoid them as best as is possible.   But they also need to be subjected to
critical appraisal, so we can be sure that we're not just dodging shadows.

kre

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jan 2003 01:48:19 -0600

> IPv4 LL address".   "Disable IPv4LL" is just a shorter way of saying 

"Disable IPv4LL" means, to me, disable all the behaviors documented in 
the IPv4ll draft.   Not only do you not acquire an IPv4ll address, but 
you don't communicate with devices that have IPv4ll addresses.   If you 
mean to disable acquisition of IPv4ll addresses, it's best to say that 
that is what you mean.

> explanation was incorrect.

If you had shown why my explanation was incorrect, I would have 
understood you.   What you did was to state that my explanation was 
incorrect, and give reasons that as far as I can tell do not show that 
it is incorrect.   I seem to be doing the same to you, so perhaps you 
can at least understand my confusion.

> that can't already be done (and I think, better, from a DoS attackers 

Why don't you describe the DoS attack that you think is equivalent to 
the DoS attack that RFC2563 enables?

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 28 Jan 2003 10:02:43 -0000

> From: "Robert Elz" <[email-masked]>
>

There are actually three definitions of "Disable LL" flying around which are
causing confusion.

1. Disabling IPv4LL *on a link" must mean to to prevent any traffic on that
link using LL addresses (source or destination).

Disabling IPv4LL *in a host* whether manually or by remote means (e.g. DHCP)
could mean two things:
2. Simply to prevent that host acquiring a LL address.
3. To prevent that host acquiring  a LL address and also to prevent it from
communicating with other LL hosts.

It is clear that disabling LL *on a link* requires much tougher measures
than either of the others - and 2 and 3 are both possible steps towards
achieving 1.

I think that if we could reach consensus on 1 then the others could be
discussed more clearly. This is the question:

Should a mechanism be mandated or recommended whereby all LL communication
*on a link* can be stopped - even if this means that some hosts can then not
communicate on that link at all?

Philip

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jan 2003 17:29:24 +0700

Date:        Tue, 28 Jan 2003 01:48:19 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | "Disable IPv4LL" means, to me, disable all the behaviors documented in 
  | the IPv4ll draft.

This confusion has existed before, I believe.   So, yes, it would be
better to be more precise.   I will try in future.

  | If you had shown why my explanation was incorrect, I would have 
  | understood you.

I thought I did that.   You didn't ever say why you thought my analysis
was wrong, or question any of it, or even ask for an explanation.
You just repeated your claim, so I just repeated myself as well...

  | What you did was to state that my explanation was 
  | incorrect, and give reasons that as far as I can tell do not show that 
  | it is incorrect.

What about my reasons was lacking?   You questioned none of them.

  | Why don't you describe the DoS attack that you think is equivalent to 
  | the DoS attack that RFC2563 enables?

OK.   We both assume that somehow a "rogue" DHCP server can answer
someone's DHCPDISCOVER.   Since we're both assuming that, how it gets
done is immaterial (that is, how the rogue server finds the correct
transaction ID and knows when is the right time to send its bogus
reply - this is obviously trivial if the server is on the same link
as the client, and relatively harder if it is elsewhere).

Your rogue server (using 2563) sends yiaddr=0.0.0.0 opt 116=0, which will
cause the client to fail to configure an IP address, and not configure
a LL address either.    That's the apparent problem, right?

My rogue server (not using 2563) sends yiaddr=10.11.12.13 and probably
subnet mask = 255.255.255.240 default gateway=10.11.12.1 (or something).
The host configures the address given (which no-one else knows, being
essentially a random number) and no LL address (as DHCP has delivered it
another address to use).   At this point it cannot communicate over the net
with anyone, as anyone else attempting to reach 10.11.12.13 will send
packets to the local router (which will either drop them or forward them
away).  The node in question will ARP for 10.11.12.1, which does not exist
on the local link, before sending packets to any address it wants to
locate, either not get an answer, or (perhaps) get a proxy-arp reply from
the router, which will then sends its packets to oblivion or nowhwere.
(One may assume that the rogue DHCP server knows what addresses will not work,
and assigns those to the node).

In both cases, the node is essentially isolated from the network.

Now let's look at the differences between the two cases.

In the 2563 case, if the real DHCP server, assuming there is one, sends
a reply as well, any rational client would use that reply instead of the
one from your rogue server - it is easy to tell the two of them apart.

On the other hand, in the "can already do it without 2563" case, if there's
a real DHCP server, sending a good address, at best it will be up to
chance as to which reply the client chooses - perhaps the first to arrive.
If it helps its case here, the rogue server can send dozens of (different)
bogus replies, appearing to all have come from different DHCP servers.
What's more, as it isn't having to do any real lease allocation, it can
most likely reply more quickly (or more slowly if it prefers, or both)
than the genuine server.

So, here, the 2563 case is less effective than what exists already, right?

Next, in the 2563 case, since the node has been given no lease, it has
no lease time either, and it is free to try again, to obtain a lease (or
to be permitted to config a LL address) reasonably soon - the node may wait
a few minutes, on the assumption that conditions are unlikely to have
changed more rapidly than that, but waiting more than 10 mins or so would
seem pointless.

On the other hand, in the "no 2563 case" the node believes it has a valid
lease, which may have been sent with the timers indicating that the first
renewal attempts should start in a year from now (with the lease valid for
2 years or more).  Since it has no reason at all to believe its lease to
be invalid, it has no reason to do anything more with DHCP for a year,
so it won't recover anytime soon.

Third, in  the 2563 case, the node knows it has been denied network
access, so it can use whatever non-network mechanisms it might have to
make this clear to anyone who might be investigating why it isn't functioning.
In the non-2563 case, the node believes it is configured and functioning
perfectly (though not getting responses from anyone - which is actually a
normal operating state for many devices), and so would be indicating via
whatever means it has "all is OK".

The only difference that weighs against the 2563 case that I can see, is
that in the non 2563 case, the device's network stack still believes it
is working, so if you can somehow guess what address it was allocated,
you could configure some other device on the same LAN to be able to
communicate with it (how you figure out which of the ~ 2^32 possible IP
addresses it was given, especially for a relatively passive device, I
have no idea though - and if it happened to be given 127.1.2.3 and had
a DHCP client that didn't recognise that such things are bogus (which is
likely) and a network stack that does know that 127.0.0.0/8 packets are
not to be sent off the local node (also likely) then it would be completely
off the net, even if you could guess its address.

Even without the latter part, the fact that you can't mount a 2563 attack
unless you can silence a genuine DHCP server (because nodes would simply
take the offer which says "here's an address" over one which says "no address
for you") makes it such an unlikely means of attack that I don't think
it is worth much effort (in comparison to how easy it is to fake a
"genuine" DHCP reply).

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jan 2003 18:09:37 +0700

Date:        Tue, 28 Jan 2003 10:02:43 -0000
    From:        "Philip Nye" <[email-masked]>
    Message-ID:  <001801c2c6b4$66efa6f0$131010ac@aldebaran>

  | Should a mechanism be mandated or recommended whereby all LL communication
  | *on a link* can be stopped - even if this means that some hosts can then not
  | communicate on that link at all?

Regardless of the desirable answer to this question, it is
pointless to ask it here.   The only way to prevent any
communication on a link, is for the link itself to somehow block it.

I can't even imagine how you'd manage to get an old style fat orange
ethernet cable (or even one of the slightly newer, but still obsolete,
thinner black ones) to prevent anything at all.

And even where it might be possible, making this happen would be someone
else's problem, nothing to do with this WG.

The very most that this WG can possibly hope to be involved in are your
other two questions - should a node configure a LL address for itself
(or perhaps better, when should a node ...) which is clearly in scope
(along with how it should be done, when it should), and perhaps the
other, of whether a node should communicate with other nodes that have
LL addresses - which I presume would really be better rephrased as
whether a node should take special measures to enable communication with
LL addresses knowing they are local to the link, and when it should not
(as even my node, which has never heard of a LL address, will communicate
with 169.254.x.y (or whatever the magic number is) if I tell it to, and
the nearby router forwards packets for that address to somewhere where it
lives).

kre

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 28 Jan 2003 12:05:20 -0000

> communication on a link, is for the link itself to somehow block it.

I should have qualified the question by saying "between compliant hosts":

Should a mechanism be mandated or recommended whereby all LL communication
between compliant hosts *on a link* can be stopped - even if this means that
some of those hosts can then not communicate on that link at all?

There are those here who plainly want this and I see no reason that this is
beyond the scope of the WG.

You appear to be arguing that such a mechanism is impractical because hosts
would not comply (or not enough of them to make it useful). Others are
arguing that this is undesirable in principle. (Personally I am undecided
but tending to one of the latter two positions).

However, we seem incapable of framing a question, let alone an answer!

Philip

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jan 2003 19:11:29 +0700

Date:        Tue, 28 Jan 2003 12:05:20 -0000
    From:        "Philip Nye" <[email-masked]>
    Message-ID:  <006c01c2c6c5$8779d240$131010ac@aldebaran>

  | I should have qualified the question by saying "between compliant hosts":

In that case, I don't see the difference between this question and #3.
If a host is prevented from communicating with hosts with LL addresses,
all you need to do is repeat that for all the other hosts on the link.
If you can assume they're all compliant, there would be no LL communications
left.

  | You appear to be arguing that such a mechanism is impractical because hosts
  | would not comply (or not enough of them to make it useful).

No, it was impractical because the initial question seemed to be aimed
at what the link would allow, not what the hosts would do (or not do).

Now I just see it as a variation on question 3, which I have ignored for
now (having said enough on these issues already, I believe).

kre

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jan 2003 08:59:48 -0500

> communicate on that link at all?

yes.  but this should not prevent any hosts from communicating on that link,
unless they are prohibited as a matter of policy, because there should be
no LL-only hosts.

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jan 2003 09:01:31 -0500

> If you can assume they're all compliant, there would be no LL communications

true.  the question is whether compliance should compel hosts to enforce
that rule even when talking to non-compliant hosts.  I say yes.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jan 2003 12:27:37 -0600

> communicate on that link at all?

No, because this is a denial of service attack.

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 29 Jan 2003 09:37:27 -0000

> No, because this is a denial of service attack.

Quite so - but this is precisely what is being proposed by some in saying
that there must be a way for the network Administrator to "turn off" LL on
the link: denial of service by the network administrator (who of course can
do so in other ways anyway).

The only exception to this assertion would be if that network administrator
accepted that the *only* way to disable LL on the link was to grant all
hosts a "better" address AND if the draft mandates DHCP client support or
some other address override.

We have to examine the motivation for a network admin wanting to deny
service in this way. I cannot recall any cases where the mere presence of LL
on the link breaks anything except where LL hosts are involved. So what is
the justification for the network administrator being able to turn it off on
the link entirely?

Philip

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Jan 2003 06:13:19 -0500

> So what is

network admins have the right to set policies for their networks, including
individual links, for whatever reason they see fit.  it's not for us to decide
whether there is adequate 'justification' or not.

existing hosts attempt to get an address by DHCP, and if this is denied, they
don't try to talk to the network unless explicitly configured to do so.  this
has led to DHCP being used by network admins to implement policy.