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

Simon Hobson <linux@thehobsons.co.uk> Fri, 15 January 2021 14:08 UTC

Return-Path: <linux@thehobsons.co.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CB23A045E; Fri, 15 Jan 2021 06:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZnLn9J-y-yv; Fri, 15 Jan 2021 06:08:42 -0800 (PST)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9073A040B; Fri, 15 Jan 2021 06:08:41 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from [192.168.137.104] (unknown [192.168.137.104]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id D39FF64028; Fri, 15 Jan 2021 14:07:46 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <a337f8f5fa354b5882d097b0d5de59dd@boeing.com>
Date: Fri, 15 Jan 2021 14:07:44 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <34DA6280-EC54-4A74-B74A-962C49D39100@thehobsons.co.uk>
References: <cb1cb55e5b634ceea3dde33b8c8816c1@boeing.com> <085F29A9-B8F0-44DF-AD4A-9EFD39FAB183@employees.org> <a337f8f5fa354b5882d097b0d5de59dd@boeing.com>
To: dhcwg <dhcwg@ietf.org>, IPv6 List <ipv6@ietf.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1ZZkAeXDzSk6BqiCrJ4Ek7awQxs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2021 14:08:44 -0000

Templin (US), Fred L <Fred.L.Templin@boeing.com> 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