host-identifier with IPv6

[Ted Lemon]

On Mar 3, 2009, at 12:39 AM, Simon Hobson wrote:
> 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.

This is just about as unusual a network management situation as I can  
imagine, and yet it doesn't require you to preload the DHCP server  
with Mac addresses, so I'm not sure why you mention it.

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

This is my point:

	1. It is not a common requirement.
	2. The protocol doesn't specifically prohibit it.

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

I explained why the MUST NOT is there.   And DUID-LL doesn't produce a  
unique identifier in the default case, which is why it isn't the  
default.   The purpose of the DUID is to produce a unique identifier,  
not to solve your back office issues.   If you can use it to solve  
your back office issues as well, that's great, but it's purely a  
coincidence.

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

You're talking about a purely tactical solution (storing Mac  
addresses) and then demanding that the protocol be future-proof.

I don't understand why you're wasting to much mental energy on this.    
As near as I can understand it, you can do the hacks you want to do  
with the existing protocol, and if we were to change the protocol as  
you propose, it would create interoperability problems for many, and  
benefit for few.   And in practice, it probably just wouldn't happen  
at all, because people who write clients unfortunately tend not to  
follow discussions in the IETF or on mailing lists like this one.

As for the potential DUID clash when you ghost an operating system,  
IIRC the protocol forbids that, but of course if you do it anyway it  
will cause problems.   There are no perfect answers.   It's  
hypothetical at this point anyway, since Apple (the example we were  
using) doesn't even support DHCPv6.