Subject: [Issue 2]: Explicit Additional Mechanism to disable v4LL

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Feb 2003 08:16:44 -0800 (PST)

Most of the text here seems ok, with the exception of the last sentence:

"Where that configuration
mechanism uses DHCP, the node MUST implement the DHCP option to disable
stateless auto-configuration in IPv4 clients [RFC2563]."

If we accept the resolution of Issue 1, then we already have a way to
disable stateless auto-configuration -- provide a DHCPv4 address. As a
result, this last sentence is unnecessary.

Presumably if there were a real need for this functionality, we
would have implementations of RFC2563, but we don't. As a result, the
right thing to do with RFC 2563 is to deprecate it, not make it mandatory.

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 19:50:13 +0700

Date:        Mon, 17 Feb 2003 08:16:44 -0800 (PST)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | Most of the text here seems ok, with the exception of the last sentence:
  | 
  | "Where that configuration
  | mechanism uses DHCP, the node MUST implement the DHCP option to disable
  | stateless auto-configuration in IPv4 clients [RFC2563]."
  | 
  | If we accept the resolution of Issue 1, then we already have a way to
  | disable stateless auto-configuration -- provide a DHCPv4 address. As a
  | result, this last sentence is unnecessary.

No, that omits the possibility that what is desired is to disable LL
addressing *without* allocating a routable address.   That is, to tell
the node that there's no point configuring IP on the LAN to which it
is connected (most likely, it is plugged into the wrong place).

Note, this is not about preventing intruders from accessing the net
(which as people keep pointing out, irrelevantly, cannot be done this
way), the intent is to allow the node to discover what is appropriate
to use on the LAN to which it has been connected, which is, sometimes,
nothing.

We're lacking functionality if we don't provide any mechanism to handle
that case.

The alternative is to tell people that having their DHCP server assign
a bogus address to the end node achieves the same result (which it almost
does).   That's worse as far as DoS issues go (the node doesn't know the
address is bogus, hence has no reason to prefer some alternative offer)
and leaves the node believing that the net should be functional (sending
ARP requests, ...) when it really would be better knowing that it has
no (IP) connectivity.

Or, we could show people how to run ARP response daemons (I suspect,
but haven't verified, that "arpd" can do this with suitable config)
to prevent LL addresses being assigned (or with more sophistication,
assigned to particular nodes).   As a mechanism to disable LL addressing
this one works fine, but requires a connection on each LAN where it
is to be applied.   DHCP gives net admins no more power (less actually
as it doesn't prevent the node ignoring the 2563 advice) but more
convenience.

  | Presumably if there were a real need for this functionality, we
  | would have implementations of RFC2563, but we don't. As a result, the
  | right thing to do with RFC 2563 is to deprecate it, not make it mandatory.

We don't, what we have is a chicken and egg problem.   No servers support
it as no clients make use of it.   No clients bother because no servers
respond (and in general, client implementors prefer not to have to consider
what happens if they have no addresses - though it is something that really
needs to be properly handled).

If this WG were to mandate 2563 support in clients, then clients will start
doing it, and with that incentive, server support will appear as well.

If there was truly no demand for 2563, why would the RFC have ever been
written, and survived IETF last call, in the first place?   It is wanted,
there just hasn't been an adequate place to require its implementation before.

It only applies to LL addressing, and the docs from this WG are the first
from the IETF that have specified anything about that.

kre

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 19 Feb 2003 14:38:59 -0000

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

> ARP requests, ...) when it really would be better knowing that it has

RFC2563 actually "hands out" the address 0.0.0.0 as a way of saying "no
address for you". This alone could be sufficient to prevent LL if we noted
so in our draft.

RFC2563 also specifies a separate "turn LL on/off" option. I guess that in
the case that the network admin didn't want to give an address but was happy
for you use LL, using this option would be quicker than simply not
responding. (It would also allow the dubious case of saying "use both").

Philip

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 22:12:36 +0700

Date:        Wed, 19 Feb 2003 14:38:59 -0000
    From:        "Philip Nye" <[email-masked]>
    Message-ID:  <02f501c2d824$a3d06100$131010ac@aldebaran>

  | RFC2563 actually "hands out" the address 0.0.0.0 as a way of saying "no
  | address for you". This alone could be sufficient to prevent LL if we noted
  | so in our draft.

Yes, it would, but if we're going to go that far, the rest of what is in
2563 is pretty trivial, and potentially useful (occasionally).

Note I'm not wedded to 2563 - I didn't even know it existed until someone
brought it up here part way along.   Its only advantage over other similar
possible techniques is that it is already out there, documented, etc.

kre

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Feb 2003 07:01:46 -0800 (PST)

> is connected (most likely, it is plugged into the wrong place).

So the idea is to use this option in a scenario where DHCPv4 is being used
(otherwise the option would not be helpful) but where the DHCPv4 server is
not assigning addresses? (if it were, by LL23, use of LLv4 would not
occur). This doesn't seem like a very mainstream scenario.

> to use on the LAN to which it has been connected, which is, sometimes,

Maybe it's just me, but I don't know many instances where DHCPv4 is
supported where the intent is *not* to assign IP addresses. If such an
option is used, it would definitely seem to require authenticated DHCP, or
else it would create a security vulnerability.

> does).

"Achieve the same result" means trying to make sure that the hosts in an
organization have no IP addresses? Why use DHCP to achieve that result
(except by accident)?

> needs to be properly handled).

Actually, the causation diagram is a bit different. No customers ask for
it, because existing implementations don't use LLv4 on an interface if a
routable address is available on that interface, and they don't care about
"configured" interfaces with no usage. Vendors don't build it because
customers don't ask for it.

> doing it, and with that incentive, server support will appear as well.

Actually it's more likely that vendors will ignore the requirement,
because customers don't care.

> there just hasn't been an adequate place to require its implementation before.

2563 was written prior to shipment of LLv4 enabled clients on a large
scale, when it was thought there might be demand for the option. This
turned out to not be the case. In addition, concern arose that the option
represented a security vulnerability. So there are no current RFC 2563
implementations on any operating system, and I doubt we will see any.

---

From: Robert Elz <[email-masked]>
Date: Thu, 20 Feb 2003 01:17:39 +0700

Date:        Wed, 19 Feb 2003 07:01:46 -0800 (PST)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | So the idea is to use this option in a scenario where DHCPv4 is being used
  | (otherwise the option would not be helpful) but where the DHCPv4 server is
  | not assigning addresses?

Not assigning addresses to particular clients on particular LANs.

  | This doesn't seem like a very mainstream scenario.

More than you might think.

  | Maybe it's just me, but I don't know many instances where DHCPv4 is
  | supported where the intent is *not* to assign IP addresses.

I do that all the time.   I see lots of queries on lists from others who
want to do just the same, and are attempting to work out how.

That is, host A is allocated an address on LAN X, but not on LAN Y.

Without LL addresses, one simply uses the (ISC) dhcp server "ignore
booting" (or "deny") (or some equivalent from some other server), the
server ignores the client, which then gets no address.  At this point
it can do whatever is appropriate for a node of its type with no addresses.

With LL addresses, the node still gets no routable address, but lacking
any extra mechanism, now assigns itself a LL address, and acts as if
it is on a disconnected LAN (ie: some stuff works, perhaps, other stuff
doesn't).

Having a node tell its user (one way or another) "No network address
available" is something I can cope with, they tell me that, and I can
either fix the problem, or tell them what they did wrong.   On the
other hand, when they tell me "the network works OK, but I can't reach
ebay" (or google or whatever) - most likely the only external address
they have tried, I start looking at other potential problems.

  | If such an
  | option is used, it would definitely seem to require authenticated DHCP, or
  | else it would create a security vulnerability.

No.   We have been through all of this before.   This option, itself,
is no more of a security problem than DHCP itself.   Authenticated DHCP
is useful (or not) on its own merits for general DHCP usage.  (Authenticated
DHCP in a zeroconf environment seems a little unlikely to me though.)   If
anything, the 2563 option is "better" than raw DHCP in this area, as a client
can easily ignore a bogus server sending such an option, and accept an address
from the real server clients always get to choose which offer of several to 
accept), whereas it cannot easily ignore a bogus server giving out what looks
like a normal routable address (which just doesn't work) because it has no
idea which response is bogus and which is not.

  | "Achieve the same result" means trying to make sure that the hosts in an
  | organization have no IP addresses?

Some hosts, on some LANs.    Plug your system into LAN A where it belongs,
and you get an address, plug into LAN B where it doesn't, and you don't.

  | Why use DHCP to achieve that result (except by accident)?

Because that's how DHCP has always been (able to be) used.

kre

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Feb 2003 04:55:05 -0800 (PST)

> they have tried, I start looking at other potential problems.

You are effectively using DHCP as a form of LAN access control. I don't
believe that this is one of the intended uses of this protocol, so that
adding RFC 2563 as a requirement to better enable an unsupported use of
DHCP seems like a bad decision.

If you want LAN access control, including error messages sent when hosts
fail to authenticate (or even when they don't authenticate at all, but are
unauthorized on LAN X but not LAN Y), you can use IEEE 802.1X instead.

> is no more of a security problem than DHCP itself.

I would claim that any option that can disable a host in a substantial way
should require DHCP authentication. Preventing host IP address
assignment on a given network is one of those things.

> Authenticated DHCP in a zeroconf environment seems a little unlikely to
> me though.)

The scenario you described is not a zeroconf scenario. It is a scenario in
which an admin attempts to use DHCP for access control.

> from the real server

Show me an example of a host that actually operates this way. I don't know
of any.

> and you get an address, plug into LAN B where it doesn't, and you don't.

Great, so you don't get an IP address -- but you still have connectivity
to AppleTalk, IPX, and NetBEUI. If the operation that the user is doing
happens to activate one of those protocols, things will still work. So
does this accomplish the goal of controlling access to the network?

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 10:06:04 -0500

> should require DHCP authentication.

LL can disable a host in a substantial way.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Feb 2003 10:19:51 -0500

I think the analysis of selective assignment of addresses by a DHCP server 
goes something like: it's a local policy decision as to whether a DHCP 
server responds to a request from a particular client.  Network admins 
recognize that denying an address to a client does not prevent that client 
from otherwise configuring an IP address or using other 
protocols.  However, there should be no requirement that a DHCP server MUST 
assign an address in response to a request from a client.  Someone can 
break into my house but there's no requirement that I hand that person a 
key to my front door.

- Ralph

---

From: Robert Elz <[email-masked]>
Date: Fri, 21 Feb 2003 19:46:02 +0700

Date:        Thu, 20 Feb 2003 04:55:05 -0800 (PST)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | You are effectively using DHCP as a form of LAN access control.

Not really, but something like that.

  | I don't believe that this is one of the intended uses of this protocol,

Not answering requests for addresses has always been an option for
a DHCP server.   Do your DHCP servers allocate addresses upon request
for anything and everything that asks?   Even those absurd RAS servers
that keep on asking for addresses when (accidentally) enabled?

Most people don't...

This isn't really access control though, as it controls nothing, it
doesn't prevent a node from accessing the net, or inventing its own
address to do do.   It is no more than advising the node what the
DHCP server (ie: the network administrator) believes should be done.

  | I would claim that any option that can disable a host in a substantial way
  | should require DHCP authentication.

That's DHCP.    It is DHCP that can disable the host in a substantial
way, using any of its abilities (supplying a bogus address for the
default router will do quite a bit of damage, supplying a bogus address
for the node to use will do more).   2563 itself does nothing new.

If you want to argue that using DHCP should require DHCP authentication,
please do so, but do it in the DHC WG.

  | The scenario you described is not a zeroconf scenario. It is a scenario in
  | which an admin attempts to use DHCP for access control.

There are two aspects to zeroconf.   One where there is no configuration
anywhere, and the other where there is no configuration on the node, but
there is config on the net.   The same nodes need to be able to operate in
both environments - since the node has no configuration it cannot act
differently on a net that has no config from one which does.   Hence, it
is important that the way it acts be compatible with both environments.

  | Show me an example of a host that actually operates this way. I don't know
  | of any.

Because we have no hosts using 2563 currently (that I know of anyway).
Were there any, that didn't operate that way, then they should be
fixed.

  | Great, so you don't get an IP address -- but you still have connectivity
  | to AppleTalk, IPX, and NetBEUI. If the operation that the user is doing
  | happens to activate one of those protocols, things will still work. So
  | does this accomplish the goal of controlling access to the network?

It doesn't.   It's you who believe that this has something to do with
controlling access to the net (you concluded that above).   I keep saying
that it does not - controlling access isn't what I want to do.  But you
look at the mechanisms, see that it looks a bit like access control, show
that it doesn't work as access control, and hence conclude that it is
useless... that's a very poor argument.

The aim is to advise the node what is appropriate for it to use on the
LAN it happens to have been connected to.   If that is "nothing" (in
some cases) there really should be a way to say that, shouldn't there?

kre

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 21 Feb 2003 04:24:05 -0800 (PST)

> address to do so.

Right.

> some cases) there really should be a way to say that, shouldn't there?

It seems like what you actually want is a DHCP option to display a message
to the user saying "You shouldn't be on Network X". Then you wouldn't get
the support call that is the issue here. Assuming that this capability was
available, why would RFC 2563 also be needed in the scenario you describe?

---

From: Robert Elz <[email-masked]>
Date: Fri, 21 Feb 2003 21:30:57 +0700

Date:        Fri, 21 Feb 2003 04:24:05 -0800 (PST)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | It seems like what you actually want is a DHCP option to display a message
  | to the user saying "You shouldn't be on Network X". Then you wouldn't get
  | the support call that is the issue here. Assuming that this capability was
  | available, why would RFC 2563 also be needed in the scenario you describe?

Yes, that would be useful.   Of course, it would need to be a code,
we don't want to embed English in messages to be displayed to the user.

And if it is going to be encoded, what's wrong with the encoding in 2563?

That is essentially telling the client that "you shouldn't be on this LAN".
Having the client (assuming it is this kind of client - there are clients
without displays remember) respond to that as you suggest would be an
entirely sensible thing for it to do.

kre

---

From: Ralph Droms <[email-masked]>
Date: Fri, 21 Feb 2003 09:47:22 -0500

We almost already have the right pieces in DHCP...the "Message" option 
(option code 56) "is used by a DHCP server to provide an error message to a 
DHCP client" [RFC2132, sec. 9.99].  Unfortunately, the "Message" option is 
only allowed to appear in a DHCPNAK message, and we don't have a way to 
send an explicit NAK, meaning "You shouldn't be on this link", to a newly 
booting client (that sent a DHCPDISCOVER message).  A DHCP server can send 
a DHCPNAK message in response to a DHCPREQUEST message, so the following 
sequence would be OK (although ugly; the bogus address is just a 
placeholder because the client is expecting something in 'yiaddr' in the 
DHCPOFFER message):

Client                Server
------                ------
         DHCPDISCOVER
       --------------->

         DHCPOFFER,
         yiaddr = bogus
       <---------------

         DHCPREQUEST
         requested IP
          address = bogus
       --------------->

         DHCPNAK,
         Message = "Go away"
       <---------------

And, a server can send a DHCPNAK in response to a rebooting client that 
begins by sending a DHCPREQUEST message.

If it would be useful to allow a server to respond with a DHCPNAK to a 
DHCPDISCOVER, we can certainly explore the idea in the dhc WG.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 10:12:04 -0700

> for the node to use will do more).   2563 itself does nothing new.

This is one of the reasons why I reject LL1 and LL23 - without these 
two changes, the IPv4ll failure mode you're talking about isn't 
possible, whether through happenstance or a deliberate attempt to deny 
service.   RFC2563 is in fact the innovation, because it predates these 
two proposals.

> some cases) there really should be a way to say that, shouldn't there?

As with any proposal, we have to weigh the pros and cons.   The pro 
here is what you are stating - that the administrator can advise the 
client as to the administrator's preferences.   The con here is that if 
the client always follows this kind of advice, it will be easy to gull 
the client into not using the network in situations where the client in 
fact has every right to use the network.   So on the one hand, we give 
the network administrator the opportunity to state a preference, which 
the client may or may not follow.   On the other, we have an easy DoS 
attack.

To me, the drawbacks of this approach strongly outweigh the benefits.   
There is no significant demand for RFC2563 - if there were, it would 
have been implemented.   During my tenure as the ISC DHCP server author 
and maintainer, I was never asked to provide this capability.   No 
existing client supports it - not even the open source clients, which 
easily could.   Again, I've never even been asked about it for the ISC 
DHCP client, even though the ISC DHCP client works on MacOS X and could 
be used to disable IPv4ll there.   Bernard Aboba, who has a much larger 
user base than I do, says he hasn't seen any demand either.

I realize that there are several people on this mailing list who want 
this feature, so in that sense there is some demand.   However, despite 
the fact that Windows and Mac are very popular, you seem to have 
survived so far without it.   What is the compelling need for this 
feature that makes it worth our while to open the protocol to an easy 
DoS attack that is difficult to counter and difficult to trace?

---

From: Erik Guttman <[email-masked]>
Date: Fri, 21 Feb 2003 20:07:08 +0100 (CET)

On Fri, 21 Feb 2003, Robert Elz wrote:
> LAN it happens to have been connected to.

We understand this is your aim.  What is the justification for adding 
'LAN policy awareness management' (if there is such a thing) to the
charter of this working group?  

How specifically does a node being 'advised' or not affect the ability
for nodes implementing this spec to communicate with each other?

Remember 'good ideas' are out of scope unless they answer IESG issues
(posted to the list last October) or they have such a clear and strong
rationale they can engender WG consensus.

Erik

---

From: Robert Elz <[email-masked]>
Date: Sun, 23 Feb 2003 16:27:48 +0700

Date:        Fri, 21 Feb 2003 10:12:04 -0700
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | This is one of the reasons why I reject LL1 and LL23 - without these 
  | two changes, the IPv4ll failure mode you're talking about isn't 
  | possible, whether through happenstance or a deliberate attempt to deny 
  | service.

For sure, if both LL1 and LL23 are rejected, then LL2 would no longer
make any sense.   But if they're not, then there's no extra security
issue that relates to LL2.

The conflict on all of these seems to revolve around how LL addresses
are conceived as being useful.

Some of us see them as a "fall back" - an address that is available and
can be used in situations where there are no other possible addresses,
that is, where there is no-one doing any network config

Others seem to see LL addressing as solving some other problem, allowing
access to nodes which have been mis-configured, and all kinds of other
exotic possibilities like that.

To me, the former fits within the charter, and the latter does 
not.

	The goal of the Zero Configuration Networking (ZEROCONF) Working
	Group is to enable networking in the absence of configuration and
	administration.

Nothing about correcting node misconfiguration.

  | As with any proposal, we have to weigh the pros and cons.

Of course.

  | The con here is that if 
  | the client always follows this kind of advice, it will be easy to gull 
  | the client into not using the network in situations where the client in 
  | fact has every right to use the network.

This is just like using DHCP - if a node is to take advice from the
administrator, it is always possible for someone to pretend to be
that admin, and give inappropriate device.

Anywhere we want administrative control we have that problem - in zeroconf
where by definition we cannot configure, and hence cannot indicate who is
an appropriate administrator, it is necessarily worse.

The question is do we sacrifice all possibility of any administrative
control, in order to remove one possible way of denying access.   If it
was the only way, the argument would be stronger, but it clearly isn't.
Someone who wants to deny hosts access to LL addresses can easily do so
using ARP.

So, your argument is that a tool should be removed from legitimate admins
in order to force interlopers to use a different method?   That doesn't
sound very persuasive to me.

[Aside:  I have just started running arpd on a NetBSD host with two
LAN interfaces. the arpd.conf file says

	if ex0
	arpnet 169.254.0.0 arpmask 255.255.0.0

	if fxp0
	arpnet 169.254.0.0 arpmask 255.255.0.0

It seems to work just fine... - but is an incredibly crude way of doing
what would be much nicer accomplished via the DHCP server.]

  | To me, the drawbacks of this approach strongly outweigh the benefits.

I see zero significant drawbacks.   That is, the DoS attack using this
(which only works on nets without a legitimate DHCP server anyway - which
mostly means on ad-hoc nets - which are generally the kind of net created
by a few friends who meet at some remote location) is easily possible
other ways.   The benefits may not be very large for many sites, but they
easily outweigh this non-disadvantage.
  
The right way to handle this, IMO, is to include LL2 (& LL23) in the spec,
and then see what happens.

When we are ready to go to DS, then if no-one has bothered to implement
the LL2 method, it can (and what is more, must) be removed from the spec.
Similarly, if at that point you can argue that having been implemented,
it is being used for DoS attacks, or simply isn't being used by anyone
at all, then it could also be removed.

But for sure, if it isn't included now, it won't be implemented, and there
would be no reasonable way to ever include it later.

Yes for LL2.
Yes for LL23.   (and LL1 becomes irrelevant).

kre

---

From: Erik Guttman <[email-masked]>
Date: Sun, 23 Feb 2003 12:39:43 +0100

Robert,

[WG chair hat off]

What is your argument?

   It is necessary to enable network administrators to be
   able to force normal hosts (not attackers) to not
   autoconfigure on the LAN because ...

An administrator can't do this today.  Even though hosts
have been doing autoconfiguring on LANs for the past 5 years,
only one actual network administration was concerned enough
to express this and give a concrete argument why this is
necessary. (This was the university where Ryan Troll
worked, before going to @Home and writing RFC 2563.)

The argument was:  We paid for the wires in the dorms.
We want students to pay to use them.  The students who had no
problem paying for network resources at the university (they
had to register their mac address in order to get a DHCP
assigned address, and access to the university network).
The students, however, had brought additional PCs and macs
to play network games on LANs.  Is this the concern you want
to address with issue LL2?  If not what do the 'network
administrators' you refer to *want to do*?

The counterarguments were:  LAN based access requires nominal
network resources.  Further, there was a genuine concern that
service providers in the late 90s would conclude that since they
owned the gateway, they could determine the behavior of the
network beyond it and make additional money.  If customers pay
per-address, why not require them to buy more addresses in order
to run additional IP hosts?  This option would remove the autonomy
of affected LANs in homes and small offices.  This would reduce
the simplicity and reliability of LAN based workgroup (file
sharing, print sharing, etc) networking, and consequently client
vendors have had no interest in this 'feature.'

   Reduced simplicity is the result of changes in the way it
   works depending on where the feature is used.

   Reduced reliability is the result of changes in whether it
   works before and after the gateway has been turned on.

If LL1 or LL23 is accepted, simplicity and reliability can
be retained by retaining LL support for old connections and
transitioning to configured addresses for new ones.  Further,
an administrator who did not want LL on his network will simply
have to assign addresses to those hosts and get this result.

Erik

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Feb 2003 10:25:55 -0700

> exotic possibilities like that.

The example that I described, where two people meet over lunch with 
laptops that got DHCP addresses at their respective work locations is 
not a misconfiguration.   Can you point to a place in RFC2131 where it 
says anything other than that the two devices are doing exactly the 
right thing?   And yet they have incorrect configurations.   So you 
can't argue that it's not useful to handle this case in IPv4ll.   You 
*can* argue that it's not useful *enough* to justify the cost, but your 
argument that it's not useful is not valid.

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 24 Feb 2003 01:11:35 -0500

> charter of this working group?

Just as a point...when I have been teaching seminars on OS X to IT groups,
and I talk about Zeroconf/Rendezvous, the *biggest* question is "Where's the
off switch in case we need to totally disable it?"

Manual turnoffs are needed.

john

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

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 24 Feb 2003 10:10:15 -0000

> From: "Ralph Droms" <[email-masked]>
>

I think that this would be useful.

A variation would be to formalise the message DHCPOFFER with yiaddr=0.0.0.0
to mean "I'm here but I'm not giving you an address" which would I suppose
allow a subsequent DHCPREQUEST to then return an DHCPNAK with a message.

This is off topic for this list but somewhat relevant. I won't pursue it
further here, but I don't have the energy at the moment to join the DHC WG.

Philip

---

From: Robert Elz <[email-masked]>
Date: Tue, 25 Feb 2003 17:55:30 +0700

Date:        Sun, 23 Feb 2003 12:39:43 +0100
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <[email-masked]>

  | What is your argument?

It certainly isn't what you seem to believe it is.

  | An administrator can't do this today.  Even though hosts
  | have been doing autoconfiguring on LANs for the past 5 years,

I suspect that many sites don't realise that LL addresses are being
configured - nodes that configure them tend to "not work" just the
same as nodes that have no addresses.  I had someone ask me a couple of
months ago why they were unable to fetch their e-mail - turns out that
the problem was that the DHCP server had died for some reason or other,
and the system concerned had configured itself with a LL address, and
as far as it was concerned, everything was fine.   To the user, the
system had an IP address (numeric values of IP addresses mean little to
most people, and 169.254 is actually close enough to the address it
should have had that there was nothing "obviously" wrong).

Now this was a laptop (or desktop, I forget) and so looking into it was
no great problem - and it was fairly obviously not working, so having a
LL address wasn't doing it any real harm (it certainly wasn't doing it any
good though).

Where there start to be problems is when we have devices that don't have
fairly comprehensive user interfaces - that is, where looking from the
outside to see what is going on inside is difficult.

Such a device can't treat obtaining a LL address as a failure, as in
isolated networks (zeroconf nets) that's what is supposed to happen.

On the other hand, in a managed network, getting a LL address is failure,
and the device really needs to be able to report, however it is able to,
that it is inoperable.

For example, where I work in Melb (which isn't where I am now) there's a
LAN to which all printers, and aside from the router(s) absolutely nothing
else is connected.   Printers get addresses using DHCP.   If a new printer
is connected, and the DHCP server doesn't give it an address (fixed addresses
are assigned, as there needs to be a known relationship between the printer
and its location - which is the only distinguishing feature between many
of the printers - yet people want to print to one specific printer, not
one on another floor at the other end of the building) then it is easy
currently to detect that, and discover why no-one is able to print anything
on the printer (showing 0.0.0.0 as the IP address is a dead give-away, to
any tech or tech assistant).

On the other hand, getting 169.254.xxx.yyy makes the printer look as if
everything is working - do you really expect the kind of person who takes
a job whose job description is "make sure the printers all have paper in
the paper trays, and that toner hasn't run out" to understand that
169.254.xxx.yyy is materially different from 169.245.xxx.yyy ?

As far as the printer is concerned, it is functioning fine on a zeorconf
lan - so it can't provide any kind of "network config failure" message
for assistance.

Maybe the reason that there aren't more problems like this is that so-far
the only place LL addresses are used are in workstation type devices,
where the difference between working and not working tends to be obvious
(they tend to initiate connections, rather than passively waiting for
someone to talk).

  | The argument was:  We paid for the wires in the dorms.

This is an access control argument.   It is bogus, and shooting it
down one more time gets us no-where.   Clearly anyone who wants to
specifically configure their system to avoid a DHCP hint can do so,
trivially easily.

Once again, the aim is to advise hosts that actually want to know
whether or not they should bother using LL addresses, whether using
one is productive or not.   This should be all hosts (subject to
user override of course, just like everything else), as the host,
without configuration, can't possibly know whether using LL addresses
is going to be useful in the environment it finds itself or not.

It is *NOT* to control access to the LAN.

Nor does this have anything at all to do with simplicity or reliability
or anything else like that (in the sense of whether or not having multiple
addresses is worthwhile) - that is all being considered under other issues.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 25 Feb 2003 18:41:38 +0700

Date:        Sun, 23 Feb 2003 10:25:55 -0700
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | > Others seem to see LL addressing as solving some other problem, 
  | > allowing
  | > access to nodes which have been mis-configured, and all kinds of other
  | > exotic possibilities like that.
  | 
  | The example that I described, where two people meet over lunch with 
  | laptops that got DHCP addresses at their respective work locations is 
  | not a misconfiguration.

No, but nor did anyone suggest that LL addresses shouldn't be used there.

  | Can you point to a place in RFC2131 where it 
  | says anything other than that the two devices are doing exactly the 
  | right thing?

    3.7 When clients should use DHCP

       A client SHOULD use DHCP to reacquire or verify its IP address and
       network parameters whenever the local network parameters may have
       changed; e.g., at system boot time or after a disconnection from the
       local network, as the local network configuration may change without
       the client's or user's knowledge.

If that isn't clear enough, then perhaps 2131 should be revised.  But
this is not the place to do that.

Now, assuming that the friends who meet over lunch didn't carry their DHCP
server along with them (if they did, it can just assign them all addresses,
right?) then they're not going to get a response when they attempt to
reacquire their network parameters, as required above.

When that happens, the first thing to note is that this clearly has nothing
at all to do with LL2, as in this scenario, there clearly isn't going to
be anything telling the nodes not to use LL addresses.

So, the nodes are quite at liberty to configure their LL addresses when
this happens (DHCP config having failed).

What's the issue supposed to be?

3.7 of 2131 goes on to say that the node may (not even MAY) continue to
use its lease until it expires, if it wants to, it doesn't say that it is
required to.

Personally, I think I'd do what the ISC client does (your code, I believe)
and attempt to determine if some previous (existing) lease is valid or not.
If it looks as if the previous address works, then go ahead, use it.   But
don't just use it because it was the address I used 5 minutes ago, unless I
cannot get any other address at all (but in this scenario I can, right - I
can get an LL address).

Now if it happens that the friends meeting over lunch all had previously
been assigned 192.168.1.x addresses, and there's still something answering
at 192.168.1.1 (very likely intended to be the default router) then they
may end up all believing that they're still on their home nets, and
keep on using their home addresses.   So?   They're all still able to
communicate.   If two of them happen to clash, then they'll know they have
a problem with their addresses, and being unable to get new ones, will
go ahead and assign LL addresses.

If one (or more) of the friends had a 172.16.x.y address, then it is
almost certain that it isn't going to find its router, or something
pretending to be it (after all, we're assuming something has answered
at 192.168.1.1) - so they're going to detect that their routable addresses
don't work, and configure LL addresses.

What's more, since LL19 was rejected, we are requiring that nodes with
routable addresses be able to communicate with nodes that happen to have
only LL addresses, so everyone is able to communicate (with each other),
right?

Of course, it is possible to dream up some unlikely scenarios where this
might fail (nodes just happening to have addresses on their home links
that are the magic "test for working" address on someone else's link), so
everyone believes they are still at home, but with diverse addresses.
Personally I think the chances of that are so tiny that it isn't worth
worrying about - and in any case, it certainly has nothing to do with LL2.

  | And yet they have incorrect configurations.   So you 
  | can't argue that it's not useful to handle this case in IPv4ll.

No, and I don't want to.   Ad-hoc networks are the primary example of
why zeroconf (LL addresses) are useful in the first place.

But all of this has nothing to do with LL2 at all (clearly) - its only
relationship would seem to be with LL23 (or LL1).

And for the argument to carry much weight there, you have to assume that
the implementation was done by someone with no clue as to what might happen,
and no interest in actually making it work correctly.

  | You 
  | *can* argue that it's not useful *enough* to justify the cost, but your 
  | argument that it's not useful is not valid.

No, the argument quoted above (which was in the context of LL2) related to
the suggestion that LL2 should not be allowed, because it enables people to
disable LL addressing in a node which is otherwise misconfigured, and so
cannot be reached.

Clearly that cannot be on a zeroconf (ad-hoc) LAN, as the fiends at lunch
is assumed to be, as there there's is nothing to give the LL2 type advice.

kre

---

From: Erik Guttman <[email-masked]>
Date: Tue, 25 Feb 2003 13:11:02 +0100 (CET)

Please hold further discussion of these issues.  We have all had an
opportunity to air our views on this.  I now need to work on a consensus
call and issue a new set of last call issues.

Thanks and regards,

Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 25 Feb 2003 20:19:58 +0200

> should have had that there was nothing "obviously" wrong).

Isn't that just a user interface problem? The laptop should tell the
user "I'm ok for networking" if it has a routable address, "I can only
do limited networking" if it only has a LL one, or "I can't network at
all" if it doesn't have anything. Given the right input, users can learn
what to expect in different situations.

	MikaL