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

Ted Lemon <mellon@fugue.com> Fri, 15 January 2021 14:26 UTC

Return-Path: <mellon@fugue.com>
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 EDB8D3A0964 for <ipv6@ietfa.amsl.com>; Fri, 15 Jan 2021 06:26:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 y9ynKevYUB9Z for <ipv6@ietfa.amsl.com>; Fri, 15 Jan 2021 06:26:07 -0800 (PST)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F903A0965 for <ipv6@ietf.org>; Fri, 15 Jan 2021 06:26:06 -0800 (PST)
Received: by mail-qk1-x731.google.com with SMTP id z11so11750856qkj.7 for <ipv6@ietf.org>; Fri, 15 Jan 2021 06:26:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=cjrai0fSlzYpzCCBP5ALj4WsZyxD/EOgP/kHYvALz4c=; b=l7zMkIOJxIQUChnzdQhRv9JW7H5TVLEegFH9UpxCWn3FzL7wwfPYQtq9Apl6Bfcgr1 K+C13lpdI/7nSoZyNMsn7kTr8eVS/6SLrYFBs44hOCNkGWyCh3cBCr29vFz99+qrLiS8 YfoVT+CHSvVj7bYi2MW5uP6dh/1prYyxbpEmZCoacHWDa5kCesyxCTJ+kJObkuNGEKlD ZX7gwsRnkwrHweGT1Xm9c+ONUZfU38AWzTQBRteO/B+A0Es2dpc4mWg/60lErDHE2iU+ hwyo5u7DP9Xw0qJSJ3kTZAxKKPKHx0+HpUtaDJc6QXmI5X5eXKuM4R5f9jEhelvOXMkR 9wAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=cjrai0fSlzYpzCCBP5ALj4WsZyxD/EOgP/kHYvALz4c=; b=jQH3J+AsP4LupH4TXkWvPR3sjvAbdtwo6eEMGpDrrU5FytJoRdOVs/bPYTCj3+X9nO I8hIOmBS6nbD9uI8jqKHrlthir0yXK6ntqGdFtWr3FkCT1pK/cLSGQtQXYQiUuXV3BuI IO9e7FgVnznJy9teIBWX0PEjIzddyi+pvQL30mG8Vu53VAk7lcIFc61N3QEb9+Dd94Ib crmI9NOjv7R9ohFlMojF4C5tPO51oTk3i6jmptZwn6V5l4YTbvUY/1Qm8fuwtFs1zkPz O1aiqIUkZlgcl15XjBqrrM7xCm7C5i00C7b/OOCaDydWyUe7JrkGDH+rEv0L9KHZAHKj hHqw==
X-Gm-Message-State: AOAM5311Ofq0aNqcvrawTYH0xHxSb3eDKG1f9PPWYr5G5P9yQp84hEPy B1clsDfxnom1HPNYXBO2Ci56u8IwF4PJLQ==
X-Google-Smtp-Source: ABdhPJzlaQT0PX8CbqjsYXdGrdiBNp+C4yDOYlcX85PLggNWmVhFZnG4X/w2TX/3shurPOmurEBssw==
X-Received: by 2002:a37:4a82:: with SMTP id x124mr12519287qka.458.1610720765694; Fri, 15 Jan 2021 06:26:05 -0800 (PST)
Received: from [192.168.4.114] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id g189sm5065039qkf.8.2021.01.15.06.26.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Jan 2021 06:26:05 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
Date: Fri, 15 Jan 2021 09:26:03 -0500
Message-Id: <7D925C73-251A-4F79-8DA0-2486846874BF@fugue.com>
References: <34DA6280-EC54-4A74-B74A-962C49D39100@thehobsons.co.uk>
Cc: dhcwg <dhcwg@ietf.org>, IPv6 List <ipv6@ietf.org>
In-Reply-To: <34DA6280-EC54-4A74-B74A-962C49D39100@thehobsons.co.uk>
To: Simon Hobson <linux@thehobsons.co.uk>
X-Mailer: iPhone Mail (18E118)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JskwKUgwY1Ok5a_a8Y86LQO5P2c>
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:26:09 -0000

Also, why not use DUID-EN if you have a specific use case for this that is not something that makes sense to standardize?

> On Jan 15, 2021, at 09:08, Simon Hobson <linux@thehobsons.co.uk> wrote:
> 
> 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
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg