Help with DHCPv6 client-identifiers

[Peter Grandi]

[ ... on DHCPv6 client ID selection ... ]

> And your suggestion for a unique*, invariant**,
> deterministic***, and always available**** identifier is ?

Whatever floats your boat :-). It is a rather difficult
architectural decision, which must be carefully considered in
the context of architectural decisions about IP address
policies, DNS policies, how much static/dynamic config to have,
whether centralized or local etc.

As an aside ultimately what *I* really care about is not interface
addresses, and not even node IDs, but filesystem IDs, as moving
disks or copying filesystems between nodes is easy (if one thinks
ahead about it). So wherever I can I try to have really arbitrary
IP addresses etc., and even node names, and present to client
systems service based server names and local locators, as in:

  nfs.example.com/filesystemid/filepath

and then map them to whatever is running them that day (which
could be '/fs/fs006/' on 'nic02.node003.example.com'). But that's
a longer discussion.

[ ... ]

> ** The majority of devices where this is being called for don't 
> change their hardware address frequently (or at all).

But devices do get moved more or less accidentally from one node
to another. Being stuck on device addresses really means keeping
careful track of which devices are in which node's box.

> [ ... ]

> **** Any device with an ethernet like interface will have one.

And we all use IEEE 802 stuff, but IPv6 is designed to be link
layer independent, and to be usable for many many decades (I
suspect that the design life of IPv6 is around a century, and
10-15% of that has already elapse), and who known which link
layers will be there in 50 years.

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

That's entirely correct, because it is really really really
outside the scope of a protocol. It is a site architectural
issue, and all that is required is that DHCP support whatever
the site chooses.

> The problem with any client-side generated identifier that is
> not **required** to be in a fixed format (like MAC address)

Again, the link layer is not encessarily Ethernet like, now or
in 50 years time. We are talking about IPv6 and DHCPv6 which are
not designed for the short term.

> [ ... ] If you have uncontrolled clients - you don't have any
> prior knowledge of what format it will be. [ ... ]

This is an insane statement if taken literally. If you have a a
truly uncontrolled client, don't give it an IPv6 address: block
the link port on which they are attached.

If the client is indeed controlled (belongs to an internal or
external customer), you can simply tell whoever runs it to use
"X" which you have yourself generated (according to your overall
technical architecture) as the client ID for DHCP, and it is
their problem to achieve that, configuring whichever OS they run
in the client HOST and its DHCP client appropriately. They don't
do that, they don't get an IPv6 address. You put that in the
SLA, it is all good.

What you are really saying is that you don't want whoever runs
the controlled client to have to do that explicitly, and you
want to default "X" to something that is implicitly part of the
client host profile, like the link layer address. And you want
the DHCPv6 server to do the job of inferring "X" from the client
profile, e.g. by lifting it out of the link frame in which the
DHCP request arrived.

That's all reasonable and fine, and I would not mind the DHCPv6
server having a crass option to modify the received DHCP packet
inserting in it the source link address as client ID if there is
no client ID already.

But that's a very different thing from the proper ways of
handling this which are:

  * The DHCPv6 client sw uses some sort of GUID as client ID
    which may not at all be related to the link layer address.

  * The DHCPv6 client sw optionally defaults the client ID to
    some suitable representation of the source link layer
    address.