host-identifier with IPv6

[Ted Lemon]

On Mar 2, 2009, at 12:44 PM, Simon Hobson wrote:
> All this adds up to a hell of a lot of "should mostly work" which is
> not what most administrators want. Sitting on the sidelines, it does
> seem to me like the key element missing here is for all IPv6 devices
> to have a fixed, immutable (or at least as close to that as a MAC
> address is now), globally unique identity that is easily obtainable
> by administrators. In the absence of anything better, up until now
> we've been using the ethernet MAC address of the interface - though
> as has been pointed out, this isn't always ideal.
>
> Without such a unique identifier, it seems to me like quite a few
> administration schemes are likely to be tricky to implement, if they
> are implementable at all. It's one thing saying that the MAC address
> (nearest thing we have to a globally unique and unchanging
> identifier) is embedded in the DUID - but I'd be wary of relying on
> something that is a) something the spec says not to do (look inside
> the value and attribute meaning to it), and b) is only guaranteed to
> the confidence level of "it's likely".
>
> I fear it's too late to fix that now as it would require changes to
> existing clients - and there's no guarantee of that happening.

I applaud you for your optimistic view of DHCP implementors.   Here's  
the problem.   The Mac address *can't* be a unique identifier, because  
it can change, either because of hardware changes or because the  
address prom gets reflashed.   Or, on some types of hardware, because  
there is no fixed hardware address.   But we want a stable, unique  
identifier.   So we get our uniqueness from a combination of the Mac  
address and the time, because it would take a fairly surprising  
coincidence to make both of them be the same on two different nodes,  
and then we keep that address in perpetuity.

But we, the authors of the protocol, do not and cannot control  
hardware vendors.   Even if we could spec out how hardware should work  
in the future, we can't say how it should have worked in the past,  
because the past is already written.   There is plenty of hardware out  
there that can do DHCPv6 but that was shipped before DHCPv6 became  
something anybody except a few geeks at IETF like me gave a damn about.

Consequently, we can suggest all we want, and propose all we want, but  
we can't legislate.   We can't say "thou shalt" about peoples' boot  
prom implementations, for example.   And we can't write the protocol  
in such a way that the vendors' behavior can't screw it up for you,  
the long-suffering administrator, because there are constraints that  
we have to deal with that simply aren't in our control.

So like it or not, your solution has to be adaptive.   It would be  
nice if it were otherwise, but complaining about it isn't going to  
change it, and believe me, if there were a way to do what you want in  
the protocol spec, we would have done it.   It's easy to postulate  
perfect solutions in a vacuuum (say that three times fast), but you've  
been on this mailing list and doing DHCP long enough to know just how  
likely it is that vendors will even read the spec, much less follow it  
if it's inconvenient.