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

Bob Hinden <bob.hinden@gmail.com> Tue, 12 January 2021 18:22 UTC

Return-Path: <bob.hinden@gmail.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 8B77A3A0EBC; Tue, 12 Jan 2021 10:22:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 F-seYBePh3h9; Tue, 12 Jan 2021 10:22:01 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 416863A0EAA; Tue, 12 Jan 2021 10:22:01 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id c5so3523044wrp.6; Tue, 12 Jan 2021 10:22:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 smtp.gmail.com with ESMTPSA id m2sm4813829wml.34.2021.01.12.10.21.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 10:21:58 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <EA79C9B1-1E14-43F8-BCCB-BC51E34AD70F@gmail.com>
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: <63678946a67a457d905a2e19c0d86e02@boeing.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Mark Smith <markzzzsmith@gmail.com>, dhcwg <dhcwg@ietf.org>, IPv6 List <ipv6@ietf.org>, "Dickson (US), Sean M" <sean.m.dickson@boeing.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
References: <63678946a67a457d905a2e19c0d86e02@boeing.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_Uncb567saSb7aQzuXRZJboCsnc>
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: Tue, 12 Jan 2021 18:22:04 -0000

Fred,

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.

Bob


> On Jan 12, 2021, at 8:26 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> 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 [mailto:markzzzsmith@gmail.com]
>> Sent: Monday, January 11, 2021 5:32 PM
>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>> Cc: ipv6@ietf.org; dhcwg <dhcwg@ietf.org>rg>; Dickson (US), Sean M <sean.m.dickson@boeing.com>
>> 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
>> <Fred.L.Templin@boeing.com> 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 [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
>>> Sent: Monday, January 11, 2021 10:21 AM
>>> To: i-d-announce@ietf.org
>>> 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:
>>> https://datatracker.ietf.org/doc/draft-templin-duid-ipv6/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-templin-duid-ipv6-01
>>> https://datatracker.ietf.org/doc/html/draft-templin-duid-ipv6-01
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-templin-duid-ipv6-01
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> 
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------