Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt

[Simon Hobson <[e-mail]>]

Templin (US), Fred L <[e-mail]> wrote:

>> No. I questioned the purpose of having an IPv6 address in something that’s supposed to be an opaque identifier.
> 
> And, I said that if it were *truly* opaque to *all* examinations and references, then
> there would only ever be *one* DUID type for all time. But, RFC8415 clearly shows
> that multiple DUID types are defined and that new ones can be added through
> future standards action.

Ah, you are starting from a false premise there.

Just because something is opaque and never ever (in theory) used in any way other than "X == Y" doesn't mean there's no reason to only ever have one method of creating it.
As the idea of DUID is that it should be globally unique, ideally the method used to create it should have the most sources of entropy possible. But different devices have different constraints. That's why we have LL and LLT since adding time of creation to the pot adds entropy, thus making LLT 'better' than LL, but some devices don't have a clock (and possibly, no persistent storage) making LLT unfeasible for them - i.e. LL is inferior to LLT, but real world constraints make it necessary.

So here the difference between LL and LLT is easy to see, as are the constraints that might force you to use the inferior one.

What people are asking you is : what makes this proposal so much better than what's already allowed, given that's what's in there is supposed to be opaque and so "it's an IPv6 address" has no bearing on it's "goodness" as a unique identifier. And more specifically, why is it better than an RFC4122 UUID as defined in RFC6355 - 'better' meaning sufficiently better to justify adding to the global code base required to support it.

Both are 16 octets/128 bits long, both are intended to be globally unique, both require persistent storage available to early boot loaders. So why is the proposed 128bit value better than the already defined 128bit value ?

Simon