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

Bob Hinden <bob.hinden@gmail.com> Wed, 13 January 2021 00:43 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 B0B0C3A14FA; Tue, 12 Jan 2021 16:43:36 -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 8AauOoKRqBs2; Tue, 12 Jan 2021 16:43:33 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 6EF0E3A14FD; Tue, 12 Jan 2021 16:43:33 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id k10so59080wmi.3; Tue, 12 Jan 2021 16:43:33 -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=23ezr3MIV4Qd4fs2S/kipy6PQbM7fEqPGsJA9jPuDjU=; b=f1IgOPPd5qCy3FcN8wscAc3r22E3lPk0AZ7TzK/OtNMFE7iDae0GuyYsAgzdb1VgB3 hYm1P14/tNj/Y9QyHU82oyFosU2pc6DH/NllJObGWTfesBsIqoELSMCueb44MnKsG63z HKDVo39/JDmOJpnJt8aZIaVMxYmnGnudp4uBb1jxEf0yYTJfA9XKM0m3A6B+bpcKFQ9H lAORMd2IzRkNX1PbiIW33EdU0lyCiQHGu/U8ZJ2CJJvHUZ4iseTjU3IFGcEr2CrywMjT TlXLH4rw/IAGZfyMirltTOfgMjW9ExQjh0J/0vDmhjLzHwwSpgRi1tQpiDRfj7wcs6Kl h77A==
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=23ezr3MIV4Qd4fs2S/kipy6PQbM7fEqPGsJA9jPuDjU=; b=i0wYvGxybY/0Tzm9gAaVujGw+dSu1sYOZDMbqJuBrrPdLO7QWwF6BciRa1Xk4T3GrY t13v1wypD4J+hPtr5S2CHWi6zTou8f0mhdGEkBmEQXjssa+X0aIMKP5ZJwLaSzQd65ia q5Yd3xISJkVEhQ3HVtJ25fE4Ja6xNG0mY9Es90Gq4gJzz/1XD8nghvDOuapkiS+UEoRK f+INgZhNqcqKCHE8AWQh6RUb6j2SkEEJzzNFG4Of12XuByC1ml9c6UrBpqj2fLXjs/1t 4r/worZVpbDVM6zO7RTuUnUemIT6/YSKV9fEoxk/yT7Fe+Z1IBqAQqkkTe9K9A78ZWz+ 5Gog==
X-Gm-Message-State: AOAM530Rd5Rv7H7SFajdy7svBr3bkPH00/5E0lUVZaEHPjh7AWGTcDra jZAKb3DSHR/QOhR6y0OiUhU=
X-Google-Smtp-Source: ABdhPJway4tSuzS115Zv58WBbClplX8OmWcZRnWQ0OjX+8qKeQvgUeLpzw6LHK8PyIxEamej85IfHQ==
X-Received: by 2002:a1c:e0d4:: with SMTP id x203mr246043wmg.68.1610498611805; Tue, 12 Jan 2021 16:43:31 -0800 (PST)
Received: from ?IPv6:2601:647:5a00:ef0b:75ff:c8a0:1e91:23bc? ([2601:647:5a00:ef0b:75ff:c8a0:1e91:23bc]) by smtp.gmail.com with ESMTPSA id z13sm7665653wmz.3.2021.01.12.16.43.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 16:43:31 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <1BDA0163-158C-4C0C-9D63-BC62D170308E@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A15A4D38-7365-429C-A5F9-2A77ADD62311"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
Date: Tue, 12 Jan 2021 16:43:20 -0800
In-Reply-To: <c938d77ed2b347da8dc23e1a8190b709@boeing.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, =?utf-8?Q?Ole_Tr=C3=B8an?= <otroan@employees.org>, 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: <f6ae99d24c9447399bd3b2e3b3c029c4@boeing.com> <74460CA0-A839-4179-A162-6946456591C7@employees.org> <c938d77ed2b347da8dc23e1a8190b709@boeing.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gQu0wm9cVWxzgfU4U--yrdquHMs>
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: Wed, 13 Jan 2021 00:43:37 -0000

Fred,

> On Jan 12, 2021, at 3:05 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> Ole,
> 
>> -----Original Message-----
>> From: otroan@employees.org [mailto:otroan@employees.org]
>> Sent: Tuesday, January 12, 2021 1:34 PM
>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>> Cc: Bob Hinden <bob.hinden@gmail.com>om>; dhcwg <dhcwg@ietf.org>rg>; 6man WG <ipv6@ietf.org>rg>; Dickson (US), Sean M
>> <sean.m.dickson@boeing.com>
>> Subject: [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
>> 
>> Fred,
>> 
>> It's unclear to me what the purpose of putting an IPv6 address in the DUID is. Would you mind clarifying that?
> 
> I will add words to the next draft version.

How about telling us now.

Bob


> 
>> Are you also aware of the following restriction in RFC8415:
>>   "Clients and servers MUST treat DUIDs as opaque values and MUST only
>>   compare DUIDs for equality.  Clients and servers SHOULD NOT in any
>>   other way interpret DUIDs."
> 
> Yes, but then what is the reason why we currently have 4 DUID types instead
> of just 1? If the text you quoted above is all there was to it, and end of story,
> there would never be a need to differentiate DUID-LL from DUID-LLA from
> DUID-EN from DUID-UUID. So, this suggests there is more to the story than
> just the short text you quoted above. And, the community has supported the
> definition of new DUIDs in the past (e.g., DUID-UUID).
> 
> Thanks - Fred
> 
>> Best regards,
>> Ole
>> 
>>> On 12 Jan 2021, at 19:40, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
>>> 
>>> Bob, please see my subsequent reply to Eric Vyncke that discusses motivation:
>>> 
>>> https://mailarchive.ietf.org/arch/msg/ipv6/yOfWHSnt36Hvjr44OERjK0OFvhw/
>>> https://mailarchive.ietf.org/arch/msg/dhcwg/YZq_aPf1C82ZFT_bTdXOXVXTPW0/
>>> 
>>> Per your comment, perhaps a new section on "motivation" could be added
>>> to the draft?
>>> 
>>> Thanks - Fred
>>> 
>>>> -----Original Message-----
>>>> From: Bob Hinden [mailto:bob.hinden@gmail.com]
>>>> Sent: Tuesday, January 12, 2021 10:22 AM
>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>>>> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Mark Smith <markzzzsmith@gmail.com>om>; dhcwg <dhcwg@ietf.org>rg>; IPv6 List
>>>> <ipv6@ietf.org>rg>; Dickson (US), Sean M <sean.m.dickson@boeing.com>
>>>> Subject: Re: I-D Action: draft-templin-duid-ipv6-01.txt
>>>> 
>>>> 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
>>>>> --------------------------------------------------------------------
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>