Help with DHCPv6 client-identifiers
Simon Hobson
dhcp1 at thehobsons.co.uk
Fri Nov 18 14:12:03 UTC 2011
Bjørn Mork wrote:
>Authentication by mac address has always been broken. The address is
>user configurable. This cannot be fixed. Suggested alternatives are
>either DHCPv6 authentication, ref
>http://tools.ietf.org/html/rfc3315#section-21 or just use port based
>authentication (which all sane people already do for DHCP anyway).
But for a great many people it is the least
broken way to do it. Yes it can be fiddled with,
but then someone can manually configure a device
anyway. For most, that is not a problem.
But for a lot of people, the MAC address is a
convenient, globally unique*, invariant**
identifier which is adequate for their needs.
* Assuming the manufacturer didn't mess it up !
** As I said, for **most** devices this never gets changed.
Now, pick **any** piece of equipment, and show me an identifier that is :
1) Usually available before even powering on the equipment
2) Often even on the outside of the box
3) Doesn't change to a new random value if the
user boots a different OS, or reinstalls the OS
MAC address mostly fits the bill, nothing else
does until we come up with a global standard for
embedding a unique ID into every piece of network
connected kit AND every manufacturer implements
it.
>The DHCPv6 server does not know anything about
>the network topology near the client. In
>particular, it cannot know anything about
>possible multiple
>exit paths from the client. Having to collect network topology and
>configure the DHCPv6 server with it is just unnecessary management hell.
>Let the _routers_ announce themselves instead.
So instead of leaving an option in that some of
us wish to use, you force people to use a method
that may not suit their needs.
You work from the assumption that all devices can
be trusted to pick their own router AND you want
the same router for all devices. I can tell you
quite categorically that isn't the case for some
of the networks I manage. On those, I have
different routes for different types of data -
and for some networks the choice of route is done
by configuring the default router on the device.
By leaving out the option to remotely configure
the gateway for a device, you've imposed an
artificial constraint on how people manage their
networks. There would be nothing wrong with
letting people not give a gateway via DHCP and
let them use router announcements, but don't shut
out people for whom that isn't the best choice.
Besides, if the administrator doesn't know about
the network topology of the network he is
running, WTF is he doing configuring devices on
it.
Bjørn Mork wrote:
>I would have identified these by the (virtual) switch port they were
>connected to, both for DHCP and DHCPv6.
Which is fine if all devices are connected in
such a manner that they are each connected as the
only device on the managed switch port. If that
is the case for you then great, it certainly
isn't always - unmanaged switches, virtual
switches, and broadcast media (eg cable systems)
are all cases in point.
And, the switch port changes a darn sight more frequently than the MAC address.
So your argument is that instead of using
something that is (nominally) unique and
(largely) invariant, you want to use something
that is in fact fairly variable in most networks.
> > Which is why cablelabs added IPv6 vendor options to include the MAC
>> address... It is pretty much the only way to identify a CM.
>
>I don't have the faintest idea what the cable modem people are doing, so
>I'll just have to trust you. It sounds extremely stupid, though. If
>they can make the CM DHCPv6 client add another vendor option, then they
>could have implemented real authentication instead, preventing simple
>spoofing and replay attacks. Embedding the client MAC address in the
>DHCPv6 request is just pointless.
So lets get this clear.
Instead of a setup where the cable modem has an
identifier which needs no configuration beyond
the manufacturers giving it a unique ID (and
thereafter can be fully configured via DHCP), you
propose a system where the cable operator or
their customers need to configure each device
before it is possible to configure it by DHCP.
Like I said earlier, this discussion has been
flogged to death before. The same arguments came
out and were refuted before. I don't expect this
one to be any more productive than the last.
--
Simon Hobson
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
More information about the dhcp-users
mailing list