Review of draft-templin-duid-ipv6-01.txt

Fernando Gont <> Sat, 16 January 2021 06:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F17DC3A157A for <>; Fri, 15 Jan 2021 22:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zaAtlBufbSj2 for <>; Fri, 15 Jan 2021 22:31:43 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 171403A1584 for <>; Fri, 15 Jan 2021 22:31:38 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:d0c6:c8bb:9de4:2f86] (unknown [IPv6:2800:810:464:2b9:d0c6:c8bb:9de4:2f86]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C5084283B6F; Sat, 16 Jan 2021 06:31:34 +0000 (UTC)
To: "Templin, Fred L" <>
Cc: "" <>
From: Fernando Gont <>
Subject: Review of draft-templin-duid-ipv6-01.txt
Message-ID: <>
Date: Sat, 16 Jan 2021 03:18:23 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Jan 2021 06:31:49 -0000

Hi, Fred,

Some  comments/questions based on reading your draft (I'm catching up 
with the thread).

**** When defining transient numeric identifiers, such as this one, 
there are three basic questions to answer:

  1) What are the interoperability properties of the I-D? What's the 
failure severity if such properties are not achieved?

  2) Do a security/privacy assessment of the ID -- i.e., what could go 
wrong from a security/privacy èrspective?

  3) Suggest an algorithm that achieves #1, while reducing/mitigating #2.

In the case of DUIDs, it would seem to me that the interoperability 
properties are:

     + Uniqueness on the same network segment

     i.e., does it really matter that devices A dn B use the same DUID, 
if they never connect to the same networks?
(but, okay, global uniquenss, to the extent that's possible, is nice)

Reusing identifiers from one context into another is known to be a bad 
idea. -- yes, there are DUIDs defined in the DHCPv6 spec that do that... 
but that's generally a bad idea.

That means that using any identifier (such as a MAC address in the 
already-specified DUIDs), or re-using an IPv6 address (are you are 
proposing), is generally a bad idea. If what you need is an opaque 
unique number, then, you shouldn't overload the semantics of DUIDs.

It would seem to me that a better idea would be to generate the DUID 
from a hash of F(YOUR_FAVOURITE_ID, secret_key). -- If you want 
something that's unique-per-network, some sort of network-id would be 
useful (e.g., SSID would be an obvious choice).

**** I believe your draft should at least answer these questions:

    + are there any problems with the existing DUIDs?

    + does this new DUID type introduce improvements of any sort? ANd, 
if so, which ones?


Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492