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

Mark Smith <> Tue, 12 January 2021 01:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9267A3A086E; Mon, 11 Jan 2021 17:32:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Status: No, score=-0.599 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sJeap3_2lG1X; Mon, 11 Jan 2021 17:32:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D58F63A0868; Mon, 11 Jan 2021 17:32:51 -0800 (PST)
Received: by with SMTP id r9so774825otk.11; Mon, 11 Jan 2021 17:32:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1qK89tiCep9/OZ3oQfhvyLAaX1AY6HVfCV+EnYYiFqI=; b=olgAVIfMLjY3D7MT+bM3LgYjhVD2h5XVBGo9f0pRgaw4eGAcCld+hZLNLeY/V8Ztft mV9EyN/kOdCkQsIBTSbUqpc9WepB6QOnUJklbBlLfpZAhm4jJ0bgLIwtWqfdj+vjWU/O xjdUsFSCDabbb+wCOQBF+n3iUDcpgFhUi+Wu+pDqTTOFqYxt4nC1ARg6G1Hs7F1QEEVO ytVT/r94Xo+qHRbsghH9CkiUsGiAr7QOfhwBK7Fo4vPeJn02UW3E1Y63uJXTSFBX730R J+V9mEmuyFmM8sshpc3DZEDCegxniJdnAI4SrKPeyju7ZoyJsuHVtDoJVMqyzsSYXm2g RWlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1qK89tiCep9/OZ3oQfhvyLAaX1AY6HVfCV+EnYYiFqI=; b=kSSj+6KKyZ30r4AOR8mHovd0Q3QvEDlLKHZUObPvd+kvmQuNJN9gXq54iAXfWIj3u7 LmKtwd/nCo7OejABbQ6GKVKPH++cEHE8t0eo2tLrs9dvojuj3WM4aDf3L4GFGUM/vJYP BOzF9YR0cWFJwxF9hcjKf5PNe+SQCiI+Re96ezePxc9IaVEpRkFh/IYWlP685LRcvJ9O Ly0odHIuuFnHzfQikDTkKduRv3hO7aCelzaV85fEvBlbyWmnRXiEOVzDVnBa1TVVsWB5 SeDXU5ZFDAbNVrs5n1seD/EJZyCJhAhucZqL74X1Fh/L1dv5bSiKd8/+0QMUfvqCMUdr rsqw==
X-Gm-Message-State: AOAM532lRDBaJP7VTZ0cxcuScYb3HABkwYDmdy3dc0L6WoHCy0c7iric 0WdE+Qv+4QY1c5SceonK8VxxmPvSiK2GChvTQHA=
X-Google-Smtp-Source: ABdhPJzcsVSwTrhU14A1sXXKodEUSOKG4TEszXCmy+ITG0m0SLvDZ4/u6IgoJ5a89FYJ+TUJ9hkyaO4LzzWSzNmRWsg=
X-Received: by 2002:a05:6830:1517:: with SMTP id k23mr1276471otp.348.1610415171007; Mon, 11 Jan 2021 17:32:51 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Mark Smith <>
Date: Tue, 12 Jan 2021 12:32:24 +1100
Message-ID: <>
Subject: Re: FW: I-D Action: draft-templin-duid-ipv6-01.txt
To: "Templin (US), Fred L" <>
Cc: "" <>, dhcwg <>, "Dickson (US), Sean M" <>
Content-Type: text/plain; charset="UTF-8"
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 01:32:54 -0000

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.


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:
> --------------------------------------------------------------------