Help with DHCPv6 client-identifiers

[Simon Hobson]

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.