Help with DHCPv6 client-identifiers

[Simon Hobson]

sthaug at nethelp.no wrote:

>  > RFC reference please. As far as I'm concerned, IPv6 supports prefix lengths
>>  right up to /128. Due to various protocol brokenness, it's difficult to
>>  configure hosts with longer prefixes than /64, but that is a different
>>  issue.
>
>My guess: The language in RFC 4291 which says that interface identifiers
>are 64 bits:
>
>    For all unicast addresses, except those that start with the binary
>    value 000, Interface IDs are required to be 64 bits long and to be
>    constructed in Modified EUI-64 format.

Hmm, and allocated addresses start with (currently) 0010, so are 
required to follow this convention.

Section 2.5 says :
>Except for the knowledge of the subnet boundary discussed in the 
>previous paragraphs, nodes should not make any assumptions about the 
>structure of an IPv6 address.

So it would seem that 64bit host identifiers are mandated for most 
purposes, but the same RFC also specifies that hosts must not make 
assumptions about the structure of an address. In fact that very same 
section talks about hosts having a variable understanding of the 
structure :

>IPv6 nodes may have considerable or little knowledge of the internal 
>structure of the IPv6 address, depending on the role the node plays 
>(for instance, host versus router).  At a minimum, a node may 
>consider that unicast addresses (including its own) have no internal 
>structure
>...
>A slightly sophisticated host (but still rather simple) may 
>additionally be aware of subnet prefix(es) for the link(s) it is 
>attached to, where different addresses may have different values for 
>n

So it's far from clear !


Personally, it strikes me as short sighted to enforce such a large 
subnet size. The answer of course is that it still leaves a vast 
number of possible subnets, bt then I suspect the designers of the 
IPv4 addressing system probably also considered the address space to 
be vast.


Peter Grandi wrote:

>As to the first issue, it is indeed a bad idea as some have
>argued in previous replies to continue using an interface link
>layer address as the client ID, so it should not be enshrined
>into a revised DHCP protocol.

And your suggestion for a unique*, invariant**, deterministic***, and 
always available**** identifier is ?
* Yes, some manufacturers have cocked it up, but it's mostly unique.
** The majority of devices where this is being called for don't 
change their hardware address frequently (or at all).
*** MAC addresses survive OS re-installs, "reset to factory default" 
operations, etc.
**** Any device with an ethernet like interface will have one.

I think everyone complaining that hardware address isn't supplied by 
a DHCPv6 client would be happy if the client always supplied a 
unique, invariant, and determinable ID. Unfortunately, that was not 
included in the IPv6/DHCPv6 specs.

>Admittedly it is however a very convenient thing to do in many
>situations. But key point here is that it is not a *protocol*
>issue, or a *server* issue. All the protocol and the server
>demand is that the client supply an ID. Which ID is supplied by
>the client, which can well be the MAC address of the interface,
>should be purely a *client-side* matter.

The problem with any client-side generated identifier that is not 
**required** to be in a fixed format (like MAC address) MAC address 
for is that it's not actually usable in practice.
If you have uncontrolled clients - you don't have any prior knowledge 
of what format it will be.
In the case of some standard options (other than DUID-LL), it will 
change if the user boots a different or re-installed OS - so it's not 
an identifier for the device, but for the instance of the OS on the 
device. Where a device uses DUID-LLT, it may well reset the value if 
reset to factory settings.



Ted Lemon wrote:

>But the idea that it's completely inexcusable that we didn't use the 
>MAC address as a host identifier is pretty absurd.

I don't think people are saying you need to use the MAC address as a 
host identifier. But in the absence of anything better, then not 
having it available at all does seem a somewhat retrograde step. The 
fact that (according to a previous post) the cable modem guys are 
standardising an vendor option for MAC address rather demonstrates 
the point - if it's going to end up being used in different options 
by different groups, it would have reduced fragmentation to include 
it in the standard - once.


Frank Sweetser wrote:

>This old thread should be relevant:
>
>https://lists.isc.org/pipermail/dhcp-users/2009-March/008307.html

Like I said earlier, flogged to death in great depth.

BTW - did anything come of that suggestion to get the standard updated ?


Chris Buxton wrote:
>As an alternative, why not use SLAAC-derived IP addresses, with the 
>M flag left off? You can still use DHCPv6 for options (turn on the O 
>flag). Just make sure all servers are using EUI-64 addresses -- this 
>may require some minor tweaking on Windows systems, to ensure they 
>use EUI-64 instead of random addresses.

Ah, so devices won't be allowed to use privacy options.

>This way, the IPv6 address used by each host is:
>
>a) effectively static
>b) based on the MAC address
>...
>Once each host picks its address, you can simply enter it into DNS 
>-- possibly the host can do so itself, using DDNS.

You let clients update your DNS !

Given that some of the comments are "you can't trust MAC addresses 
because users can change them", I'd say the chances of someone doing 
that are probably a bit less than someone being mischievous given 
access to update the DNS directly. OK it's a bit different with a 
Windows AD setup where the client is already authenticated, but not 
in the general case.

In any case, it's a bit more work than just reading the MAC address 
off the box, plugging it into your "system", and having the device 
just appear on the network in an address range where you want it and 
with the DNS entries you want for it.


Again, I don't think people are particularly concerned about using 
the MAC address - all they want is a device identifier that's unique, 
invariable, and ideally identifiable in advance.
The MAC address is the nearest thing we have to this for the sort of 
applications people want to do. It's frequently printed on the 
outside of the box and so can be determined even before the unit is 
shipped. It's there before the OS is installed, and it's still there 
if you boot the system from another OS  (such as for diagnostics 
purposes).

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