Help with DHCPv6 client-identifiers

[Bjørn Mork]

Simon Hobson <dhcp1 at thehobsons.co.uk> writes:

> AIUI from previous threads (not got into it myself yet), there are 3
> forms for the IPv6 ClientID. 

Actually, there are now 4.  RFC6355 added DUID-UUID.  Ref
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#dhcpv6-parameters-6


> One of these is derived from the MAC, 

Well, two of them are _derived_ from the MAC but one of them includes a
time value which makes it somewhat unpredictable.  I guess that was what
you meant.  Anyway, RFC3315 forbids any DUID interpretation so it
doesn't really matter:

   Clients and servers MUST treat DUIDs as opaque values and MUST only
   compare DUIDs for equality.  Clients and servers MUST NOT in any
   other way interpret DUIDs. 

> but
> is generally only used on devices without persistent storage. Other
> devices generate a unique ID on first boot and then use that - 
> until you switch OS or reinstall the OS.
>
> To top it off, the MAC address (hardware) is not included.
>
> I also understand that there is no option for specifying routers via
> DHCP, though that's being reviewed ? The argument for lack of a
> routers option is that it's done by router discovery protocols - but
> that removes a lot of control from network admins.
>
> In short, it would appear that no-one using these sorts of assignments
> was involved in the standards setting process - or if they were, then
> their input was overruled.

Well, I believe they grabbed the opportunity and just removed some of
the crap that had accumulated in DHCP over the years.  This means that a
few broken features were dropped.  But fear not - a lot of new ones
were added as well :-)

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).

With IPv4 you had to match default gateway with the allocated address.
This made it reasonable to configure both using DHCP.  But this has
always been a broken IPv4 feature.  There is really no good reason why
the gateway should need an address in each and every subnetwork it is
going to route packets for.  This has been fixed in IPv6.  Which also
means that there is no good reason for the DHCPv6 server to publish
gateway addresses.  In fact, there are very good reasons not to: 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.

> * Much debate about this detail.
> For most modern systems, the MAC address is pretty well immutable - 
> it's not common to be swapping NICs, the majority are built in to the
> motherboard.

head-in-sand... You may want to consider:

a) All systems, modern or not, will allow the user to change mac address.

b) plugin-NICs are still pretty common.  Even laptop class systems may
   use e.g. USB attached NICs.

c) Duplicate MAC addresses in firmware are common enough to be a factor
  to consider.  Whether it is caused by fake hardware, users flashing
  their devices in error, manufacturing failures or other issues I do
  not know.

d) Virtual systems, without any firmware at all, are becoming more and more
  common. 

e) Etc

> The other issue is about devices with multiple NICs - eg a laptop with
> wired and wireless interfaces. The argument for not using the MAC
> address is that by using a Client ID it works the same whichever
> interface(s) is used.

Yes, this is absolutely essential.  It is a HOST configuration protocol,
not an INTERFACE configuration protocol.


Bjørn