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

["Bernie Volz (volz)" <[e-mail]>]

Fred:

I agree with Simon.

You have not explained why you cannot use one of the existing methods - even putting aside DUID-EN. Why can you not use DUID-LL, DUID-LLT, or DUID-UUID?

And, with DUID-EN, you can do whatever you want without anyone's input - of course, whether that usage is a good idea is a separate question. Yes, it may have a few additional bytes more than DUID-V6ADDR, but that hardly seems like a useful argument at this point as we still don't know why this is better than the existing DUID types for a STANDARDIZED type.

I still see no text in the 00 or 01 draft about why you need this over the existing methods - i.e., why none of the existing methods will work.

The other thing about a standardized DUID is that you have to assure it is not misused or misunderstood how it should be used. So, you need to be clear about when it MAY be used and when it MUST NOT be used. 

- Bernie

-----Original Message-----
From: dhcwg <[e-mail]> On Behalf Of Simon Hobson
Sent: Friday, January 15, 2021 9:08 AM
To: dhcwg <[e-mail]>; IPv6 List <[e-mail]>
Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt

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


_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg