Subject: Oppose: LL2 DHCP Mechanism to disable v4 LL

From: Stuart Cheshire <[email-masked]>
Date: Sun, 23 Feb 2003 14:00:40 -0800

I strongly oppose requiring the host to implement a DHCP Mechanism to 
disable v4 LL.

This makes it too easy for greedy ISPs (like the now-bankrupt @Home, 
whose name appears at the top of never-implemented-by-anyone RFC 2563) to 
exert unjustified control over what the customer may do on their own 
Ethernet network in their own home.

Ted Lemon also listed many good reasons why this is an inappropriate 
mechanism.

If you want to deny a host access to the network, then DHCP-based 
solutions are just not the right mechanism. They just encourage people to 
continue using AppleTalk. If you want to deny a host access to the 
network, then 802.1X gives you the control you want, and blocks ALL 
protocols.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

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

Date:        Sun, 23 Feb 2003 14:00:40 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | I strongly oppose requiring the host to implement a DHCP Mechanism to 
  | disable v4 LL.

That isn't what LL2 says, unless the host is using DHCP to configure
itself anyway (which is optional).

  | This makes it too easy for greedy ISPs (like the now-bankrupt @Home, 
  | whose name appears at the top of never-implemented-by-anyone RFC 2563) to 
  | exert unjustified control over what the customer may do on their own 
  | Ethernet network in their own home.

Not true.   If you have your hosts using "greedy ISP's" DHCP servers to
obtain addresses, then they can easily control your net without any
need to deny you LL addresses.   If your ISP is going to send you bogus
DHCP answers, don't use their DHCP server (or certainly don't use it for
devices where you don't want their answers).

  | If you want to deny a host access to the network,

I don't, and never did (or not this way).

  | They just encourage people to continue using AppleTalk.

Why would that be a problem?   (assuming that denying access to the
net was the aim, and that was to be done by un-configuring IP)

  | If you want to deny a host access to the 
  | network, then 802.1X gives you the control you want, and blocks ALL 
  | protocols.

Yes, I know, and already do that.   But that doesn't achieve the
objective - for some hosts, what I might actually want to accomplish
is to disable IP in the node, and have it use appletalk instead.  Why not?

But ...

[email-masked] said:
  | Since an ARP-based denial-of-service attack is possible anyway by another
  | device on the same physical link, it makes sense to standardize this,
  | instead of having different vendors each invent their own different
  | denial-of-service attack to shut down IPv4LL.

There is no need to standardise that, if the aim is just to shut off
v4LL, doing so using ARP responses is trivial.   There's no particular
reason for everyone to have to do it the same way.

If the node is going to be effectively dead anyway, however that happened,
it should go ahead and keep on trying to obtain an address - the current
draft says so anyway (keep trying, at a somewhat reduced rate, to avoid
net overload).

Adding a standard method to do this adds nothing useful at all.

But it is good to see you admit that the techniques exist (to shut down
LL usage) and cannot be avoided (which writes off Ted's argument against
LL2 which basically said that nodes should always be able to get LL2
addresses in case the rest of their config is bogus - then they can still
be managed).   Clearly it is trivially possible if anyone wants to prevent
a node getting a LL address.

What we seem to have come down to now, is not a discussion of whether or
not there should be such a mechanism, but which particular mechanism it
should be.

LL2 only says 2563 in the case of nodes using DHCP already (and I personally
don't care if it is 2563 or some other DHCP mechanism, so if someone really
wants to object to 2563 because its author worked for what some believe was
a "greedy ISP", then fine, some other method would do).

But I see no rational reason at all to make life difficult for administrators
of large nets, by requiring them to connect nodes directly to all LANS,
just so they can disable LL there when that's what should be done.
That makes no sense - it is possible, but it is an administrative nightmare.
Now the LAN I described in my recent reply to Erik, which has only printers
connected, also needs a workstation (or similar) that can answer ARP
requests - but being connected, now I also need to be able to get to iit
to manage it.   That means either I have to allow all kinds of protocols
through the filters in the router which wouldn't be necessary for printers,
or this system needs to have connectivity via some other interface.  If the
latter, then I now have two access paths to the printers that have to be
controlled, one via the router, and another via the workstation.

And all of this because you don't like the possibility that someone
to whom you have abrogated control of your nodes (by using their DHCP
server to configure them) will actually make use of that control in
a way that you don't like?

No thanks.   If the control is to exist at all (and it certainly does
exist) let's have it in a mechanism that is reasonable to actually operate.

kre