host-identifier with IPv6

[Simon Hobson]

Ted Lemon wrote:

>>This may be a fundamental difference of opinion, but the MAC address
>>of the devices interfaces is probably as stable as anything you are
>>likely to get on current devices. [...]
>
>You make some good points here, Simon, but it all boils down to the 
>life cycle of your typical client, and we can't optimise the 
>protocol to support one particularly broken client (the one that 
>requires frequent O.S. reinstalls that would wipe out the DUID - I 
>won't name it, but you know which one I'm talking about).

That's not actually a valid assumption - it's not just that broken 
glazing that gets such a treatment. For example, my local LUG meets 
in a University facility and the machines there are all setup so as 
to be quickly rebuildable in their entirity (including Linux) in a 
matter of minutes. I don't know enough about the setup, but I do know 
that they get their hostname and other settings by DHCP and load 
their OS image from a common source (via AFS I believe). I would be 
surprised if (without extra, unnecessary, work) they would retain any 
local ID across rebuilds.

>I don't mean to minimize the needs of sites that happen to run the 
>type of client that requires frequent O.S. reinstalls, but my point 
>is that we can't design network protocols around those clients.

But surely no-one is actually asking for that - what people are 
asking for is a protocol that isn't designed to specifically prohibit 
a common requirement ? It would seem to me that simply including the 
MAC address in client messages would have supported everything that 
people are asking for, without using semantics to justify doing 
something the RFC says "MUST NOT", without in any way affecting the 
majority of people who don't require the functionality under 
discussion - and is to all intents no different to DUID-LL.


>David W. Hankins wrote:
>>How does Nominum solve this problem without contravening RFC 3315's
>>MUST NOT on the subject of digesting DUID subcontents?
>
>I already explained that.   The MUST NOT is with respect to the DHCP 
>servers's behavior in the DHCP protocol.   When you're doing 
>something that is not part of the protocol (e.g., making decisions 
>about what options to send to the client that are not based on 
>requirements in the spec) you can do whatever you want.

I get this - we can't "look inside" the DUID in terms of matching 
leases, but we can when (for example) matching classes. This isn't 
how I read section 9 of the RFC which makes no such distinction - but 
lets move on.
Where it breaks down is that :

a) there is no guarantee whatsoever that a client will use DUID-LLT or DUID-LL
b) and a client may well use a new (to us) type of DUID

So we have no reliable way of extracting a persistent* unique ID.
Relying on something that "is likely to" isn't a good recipe for long 
term reliable systems IME.


Furthermore, there is now the complication that should a network card 
get moved from one device to another, or an image get moved to new 
hardware, then we can have two clients with the same MAC address if 
we do try to extract it from the DUID.


* In this case, meaning as persistent as it is practical to have it.

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