host-identifier with IPv6

[Simon Hobson]

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

Hmm, I think this has already been established - it seems to be quite 
common in educational setups.

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

See above

>	2. The protocol doesn't specifically prohibit it.

It appears to !

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

Hmm, the starting assumption here is that the MAC address isn't 
unique (that's the only way that DUID-LL can be non-unique), 
therefore anything based on it isn't unique. The MAC address is 
supposed to be unique, and duplicates already cause problems 
irrespective of DHCP. It does come across as a complicated solution 
that fixes a "problem" by making things more complicated and 
introducing as many problems as it solves - we've already identified 
as many ways to create duplicate DUIDs as there are probably 
duplicate MACs.

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

Sorry, but this comes across as "we don't care if the protocol 
doesn't work for some important real world setups - that's your fault 
for having the audacity to work around practical issues".


In the absence of some other persistent ID, unique to a device (not 
each OS/environment running on each device), and known prior to 
deployment - MAC address is the ONLY value we have. I can see the 
issues with multiple NICs, and the problems with links that don't 
have a static MAC, but what we have is, for a lot of people, the best 
compromise. In the real world, NIC don't tend to get changed all that 
often, and when they do, there are usually other things that have to 
be fixed (UDEV rules in Linux for example).

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

Granted it would cause problems to CHANGE it now, I have to wonder 
how we got to the situation of even having this discussion. Did 
no-one ask what would happen to DUIDs on multi-boot systems or when 
systems were re-imaged ? Did no-one ask how devices (such as IP 
Phones or Printers) would be provisioned in the absence of 
pre-installation identity ? I guess we'll just have to hope that 
manufacturers of such devices will employ DUID-EN and print it 
alongside the MAC on the label :-/ (what's the odds on it sharing 
octets with the MAC address ?)



I think we are just going to have to agree to differ on this.

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