Re: I-D Action: draft-templin-duid-ipv6-01.txt

Bob Hinden <> Tue, 12 January 2021 18:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B77A3A0EBC; Tue, 12 Jan 2021 10:22:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F-seYBePh3h9; Tue, 12 Jan 2021 10:22:01 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 416863A0EAA; Tue, 12 Jan 2021 10:22:01 -0800 (PST)
Received: by with SMTP id c5so3523044wrp.6; Tue, 12 Jan 2021 10:22:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pXY7KQ0T6+Eq1A7TUtDe+zcPt1SUqZU8xUzjgwJadUU=; b=nsznlHnR0EXiIp07al6VuTfQm32cA2HCojrKU6mKDKB7N/F4PDQjnQtZ3p8NPqik7S 71aSaJKUS6rQkYbpjn21pLcE0xmr21DjBK2tF2cmsT96DBSYjaye7di/IDUR31KAjdfx f3Ik3y3K2Zvke3Rjq5fy7DHVS7KKC+kbnxoNEbzB9lsxX8YHBdy4l51Yx0cerRUexpTr B+9kMpP1np5G4SSOxotT4Szw5DYuQzNaTFiwwcjGcLydd7m5jDhlCECwccBmssTGvhyX hQdIfIRJwmUN2Tme7mlNd7WqrmuUZ1FCi0VFc3RtXdis/VBxp3/NzZdMmvNW3Z2mEjLN e/bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pXY7KQ0T6+Eq1A7TUtDe+zcPt1SUqZU8xUzjgwJadUU=; b=Fsx3YINkCOucJfIuUOUrXW3QqFEjAONx9/TFWNll5ObWkPyGXiYEsNjv9XmNX+Wbs9 7XkFIKPbnlUw1f93eMk38Fq4rptGA0VV1HbkANMeMvVvzY3QwWnBxlwL11AFwk0jVAhV q+RJ2Rkpd9wpuei7eavs7f+IAFloYCefJYf9J1/gxBA3SeLKreXLLJ08jV6jCNj21TTY dq0Vxt2UjKc2UVrYAzcwogSnOT+jhenr+V5nIcEPf9Te8pDPoGQYDlTvdPTuvdV3sxto ooXPCNOJSiT/I+3s/z0/QnUDni6CDYU5i64ZVo+1iL2ofivWdiI6NHRzNm+4jxBTKVWZ csew==
X-Gm-Message-State: AOAM5312jdU6tPtG/8VNy+PcuSrXlRpbx0P79pkLwEn8dRO5CVi7YYSQ Md6Lqb+tdaO7jqhwCc+xt48=
X-Google-Smtp-Source: ABdhPJwYrfiLrwt26Ac16rsWOC3WptGSQ0PVKEcTZIDitLRDHzW1zfLd4NOktqSLNi10MWWapwj7yQ==
X-Received: by 2002:adf:8342:: with SMTP id 60mr165044wrd.140.1610475719453; Tue, 12 Jan 2021 10:21:59 -0800 (PST)
Received: from ?IPv6:2601:647:5a00:ef0b:23:807b:323d:5bd6? ([2601:647:5a00:ef0b:23:807b:323d:5bd6]) by with ESMTPSA id m2sm4813829wml.34.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 10:21:58 -0800 (PST)
From: Bob Hinden <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_9E686BA5-A413-4D48-85AD-1DEDF8728B54"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: I-D Action: draft-templin-duid-ipv6-01.txt
Date: Tue, 12 Jan 2021 10:21:53 -0800
In-Reply-To: <>
Cc: Bob Hinden <>, Mark Smith <>, dhcwg <>, IPv6 List <>, "Dickson (US), Sean M" <>
To: "Templin (US), Fred L" <>
References: <>
X-Mailer: Apple Mail (2.3445.104.17)
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: Tue, 12 Jan 2021 18:22:04 -0000


Mark asked:

"I don't understand what problem this is trying to solve or see any
benefits of it. What is wrong with existing DUIDs?”

I have the same question.   I read the draft but have no idea why this is needed.


> On Jan 12, 2021, at 8:26 AM, Templin (US), Fred L <> wrote:
> Mark, thanks for the comments. I gather your concern is for the longevity and
> immutability of the IPv6 address that would go into the DUID, since DUIDs are
> meant to identify the device and not change over time. But, there are IPv6
> address generation methods that generate addresses not for the purpose of
> assigning them to a physical interface (e.g., Ethernet, WiFi and the like), but
> instead to provide a unique node ID for the device that never changes
> [RFC7401][draft-ietf-drip-rid]. Also, [RFC7721] mentions several other IPv6
> address generation methods that could be considered for use for generating
> a unique node ID, and other IPv6 address generation methods intended to
> create a unique node ID could be defined in the future.
> So, again, this is not about using an IPv6 address assigned to a physical interface
> as a DUID; it is about using an IPv6 address that was intentionally generated to
> be a unique identifier for the node and may also be assigned to a virtual interface.
> Thanks - Fred
>> -----Original Message-----
>> From: Mark Smith []
>> Sent: Monday, January 11, 2021 5:32 PM
>> To: Templin (US), Fred L <>
>> Cc:; dhcwg <>; Dickson (US), Sean M <>
>> Subject: Re: FW: I-D Action: draft-templin-duid-ipv6-01.txt
>> Hi Fred,
>> I don't understand what problem this is trying to solve or see any
>> benefits of it. What is wrong with existing DUIDs?
>> DHCP Unique IDentifiers are, per RFC 8415,
>> "...  designed to be unique across all DHCP clients and servers, and stable
>>   for any specific client or server.  That is, the DUID used by a
>>   client or server SHOULD NOT change over time if at all possible; for
>>   example, a device's DUID should not change as a result of a change in
>>   the device's network hardware or changes to virtual interfaces (e.g.,
>> Mrugalski, et al.            Standards Track                   [Page 32]
>> ________________________________
>> RFC 8415                      DHCP for IPv6                November 2018
>>   logical PPP (over Ethernet) interfaces that may come and go in
>>   Customer Premises Equipment routers).  The client may change its DUID
>>   as specified in [RFC7844]."
>> The only IPv6 address that I can think of that might come close to
>> meeting those requirements would be an EUI-64 derived Link-Local
>> address, and that is assuming that the EUI-64/hardware MAC address
>> never changes. MAC address randomisation and the RFC8064
>> recommendation for use of RFC7217 for SLAAC means that Link-Local
>> addresses may not meet the DUID requirements above either (RFC7217 can
>> result in link-specific link-local addresses (specifically the IID
>> portion is link specifc), even though the link-local prefix itself is
>> constant across all links).
>> There's also a circular dependency if the DUID is based on a GUA or
>> ULA address and DHCPv6 is to then be used for stateful GAU/ULA address
>> assignment, unless you mandated that SLAAC and stateful DHCPv6 are
>> used in parallel so that SLAAC could be used to derive the DUID that
>> is then used to acquire further ULA/GUA addresses via stateful DHCPv6
>> IA_NAs and IA_TAs.
>> "The DUID-V6ADDR may appear in DHCPv6 and/or other protocol control
>>   messages (such as IPv6 ND) within a service domain when a unique ID
>>   based on an IPv6 address is required."
>> In the latter case, why not use IPv6 addresses themselves? Using
>> DHCPv6 Unique Identifiers outside of the DHCP protocol would be an
>> abuse of a DUID.
>> Regards,
>> Mark.
>> On Tue, 12 Jan 2021 at 05:47, Templin (US), Fred L
>> <> wrote:
>>> Hi, more and more IPv6 address generation methods are being specified that
>>> intend to generate IPv6 addresses that are highly likely to be unique on either
>>> a global scale or unique within a bounded service domain. So much so, that
>>> some address generation methods intend for the IPv6 addresses to be usable
>>> as node identifiers.
>>> Recognizing this, this document proposes a new DHCPv6 DUID type known
>>> as "DHCP-V6ADDR" that includes an IPv6 address in the body of the DUID. In
>>> this way, IPv6 addresses produced by address generation methods intending
>>> to generate a node ID can be used as unique identifiers in DHCPv6 message
>>> exchanges. This would introduce a single new DUID type, for which the IANA
>>> allocation policy is  "standards action".
>>> Alternatively, a separate DUID type could be allocated for each IPv6 address
>>> generation method. However, that approach may result in additional IANA
>>> allocations and would require implementation updates every time a new
>>> address generation method is specified. Hence, a single generic DUID type
>>> for all IPv6 generation methods is proposed, but open for discussion.
>>> Comments on the list welcome.
>>> Fred
>>> -----Original Message-----
>>> From: I-D-Announce [] On Behalf Of
>>> Sent: Monday, January 11, 2021 10:21 AM
>>> To:
>>> Subject: I-D Action: draft-templin-duid-ipv6-01.txt
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>        Title           : The IPv6 Address-based DHCPv6 Unique Identifier (DUID-V6ADDR)
>>>        Author          : Fred L. Templin
>>>        Filename        : draft-templin-duid-ipv6-01.txt
>>>        Pages           : 7
>>>        Date            : 2021-01-11
>>> Abstract:
>>>   This document defines a new DHCPv6 Unique Identifier (DUID) type
>>>   called DUID-V6ADDR that contains a single 128 bit IPv6 address.
>>>   DUID-V6ADDR makes it possible for devices to use suitably-derived
>>>   unique IPv6 addresses to identify themselves to DHCPv6 servers and/or
>>>   other network nodes.
>>> The IETF datatracker status page for this draft is:
>>> There are also htmlized versions available at:
>>> A diff from the previous version is available at:
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at
>>> Internet-Drafts are also available by anonymous FTP at:
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> Internet-Draft directories:
>>> or
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> Administrative Requests:
>>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------