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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 15 January 2021 18:57 UTC

Return-Path: <Fred.L.Templin@boeing.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 38CB73A10B5; Fri, 15 Jan 2021 10:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=boeing.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 QDOdJYtsfNdb; Fri, 15 Jan 2021 10:57:39 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525893A10B4; Fri, 15 Jan 2021 10:57:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 10FIvaRq027622; Fri, 15 Jan 2021 13:57:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1610737057; bh=wfHcU+uDiGlaiEaT76+sGwP3+7FlXetfINGItslCHBM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=YDrJQ3MTA0fDY/B2WsIPqxJc7UN9ASpG6hQKbX4dKbGb/5Jd6JcQLOZH3SdaIpG8Q CSontLTqnFrpuB/1UddD+0soFk9X9DDyXZn23aEwJywKX4jVGABEQIxkxCAB6bqnK8 GIm69qA7l2JGQUl44cUMcDtLbq7wZtamUBMfyCtgszwPt0qT0LZ3+N3/Ou3lA8sjK3 DmbUoJjwhTHV5v8nt6s9lr/DzOIh4gT9T0Id8+CTi1jwW/YoID3TVJEXOyyHu/9U3i hi7oECr+2/KHA7LpkUH+O5Ogs/OWSoHq+SMl9ThoPxHggHn5vWLibK4Kx4rJkIuZVF k12tROFH94LyA==
Received: from XCH16-02-10.nos.boeing.com (xch16-02-10.nos.boeing.com [144.115.66.76]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 10FIvM2i027439 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Jan 2021 13:57:22 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-02-10.nos.boeing.com (144.115.66.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Fri, 15 Jan 2021 10:57:21 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Fri, 15 Jan 2021 10:57:21 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: dhcwg <dhcwg@ietf.org>, IPv6 List <ipv6@ietf.org>, "Dickson (US), Sean M" <sean.m.dickson@boeing.com>
Subject: RE: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
Thread-Topic: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
Thread-Index: AQHW6pXTRFz21hDoPUmc8dx7bbRVMaon+1WA//+Gu5CAAYaScA==
Date: Fri, 15 Jan 2021 18:57:20 +0000
Message-ID: <db9339dbe4be499bba9d098732ace1a3@boeing.com>
References: <f6ae99d24c9447399bd3b2e3b3c029c4@boeing.com> <74460CA0-A839-4179-A162-6946456591C7@employees.org> <c938d77ed2b347da8dc23e1a8190b709@boeing.com> <1BDA0163-158C-4C0C-9D63-BC62D170308E@gmail.com> <1d654c0732a244e394178a38a4aa019d@boeing.com> <ed7ce7a5020348cd98222bf9bdd66eed@boeing.com> <C9AE494A-0372-4294-AC1F-E25FEAEBA4DB@gmail.com> <cb1cb55e5b634ceea3dde33b8c8816c1@boeing.com>
In-Reply-To: <cb1cb55e5b634ceea3dde33b8c8816c1@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 609DE97F809335AB7CFE5B294D37CF5893D4A98596F00821E969E3434A9555BF2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PbTbYw2qRisY8LmuKZrYS_FjtC0>
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: Fri, 15 Jan 2021 18:57:42 -0000

To everyone who has commented, this is the particular exchange for which
I have been expecting but have not received follow-up discussion on the
answer I provided. I will not answer any more questions, because I would
simply be reiterating the same answer I provided in this exchange below.

If I get no follow-discussion (especially from Bob Hinden) I will consider the
DUID-V6ADDR idea "dead" and revert to using DUID-UUID to encode 128-bit
values of all types *even if they are not UUIDs*. Would everyone be cool
with that?

Fred

> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> Sent: Thursday, January 14, 2021 11:46 AM
> To: Bob Hinden <bob.hinden@gmail.com>
> Cc: dhcwg <dhcwg@ietf.org>rg>; IPv6 List <ipv6@ietf.org>rg>; Dickson (US), Sean M <sean.m.dickson@boeing.com>
> Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
> 
> Bob,
> 
> > -----Original Message-----
> > From: Bob Hinden [mailto:bob.hinden@gmail.com]
> > Sent: Thursday, January 14, 2021 10:44 AM
> > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > Cc: Bob Hinden <bob.hinden@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: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
> >
> > Fred,
> >
> > > On Jan 14, 2021, at 8:53 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> > >
> > > Bob, I think the answer to your question is quite simple. RFC8415, Section 11
> > > provides the motivation for having more than one type of DUID, and RFC6355
> > > is an example of how new DUID types are added through standards action.
> > > The precedent for adding new DUID types according to published procedures
> > > is therefore established.
> >
> > That wasn’t the question.   I didn’t ask if other types of DUID were allowed,
> 
> A different poster (Ole) made an assertion that seemed to call into question
> why more than one DUID type is necessary - the above text was included to
> to justify why multiple DUIDs are provided by RFC8415, and why additional
> DUIDs can be added through future standards actions.
> 
> > I asked:
> >
> >  "It's unclear to me what the purpose of putting an IPv6 address in the DUID is. Would you mind clarifying that?”
> >
> > Several other people asked similar questions.
> >
> > > In the specific instance of the proposal for establishing a new DUID type to carry
> > > an IPv6 address, the intended use case is for IPv6 address generation methods
> > > that produce an address that is designed to be a unique and stable identifier for
> > > the node, which meets the requirements of what can be used as a DUID per
> > > RFC8415, Section 11. This is certainly the case for (H)HIT per RFC7401 and
> > > draft-ietf-drip-rid, and I suppose the same case could be made for other
> > > cryptographically generated IPv6 addresses such as RFC3972. Future IPv6
> > > address generation methods (whether or not cryptographic) could also be
> > > designed to produce a unique and stable identifier for the node, and would
> > > be covered under the proposed new DUID type as well.
> >
> > Again, why do you need to use an IPv6 address for this?    Why can’t one of the current DUID approaches be used?
> 
> [RFC7401] and [draft-ietf-drip-rid] are examples of IPv6 address generation
> methods that generate an address intended to be used as an *identity* but
> possible not as a *locator*. In other words, the address could appear in control
> message ID fields but may or may not be "ping'able" in the data plane. And,
> even if it were "ping'able", pervasive use of the address for data communications
> could present an unacceptable privacy exposure.
> 
> > I note that DHCPv6 is usually used to get an IPv6 address, so using an IPv6 to get an IPv6 address seems very odd.
> 
> Continuing from what I said above, yes this would entail using one type of IPv6
> address (a pure identifier) to obtain one or more IPv6 addresses or prefixes that
> can be used as the source/destination addresses for IPv6 data plane packets.
> 
> Fred
> 
> > Bob
> >
> >
> > >
> > > Before we go down the rathole of "IPv6 addresses must be assigned to an
> > > interface and not a node", please refer to the earlier messages on this thread
> > > where the suggestion was made that the stable and unique address could be
> > > assigned to a virtual interface (e.g., a loopback) and not an interface that may
> > > be subject to change such as due to a hot-swap of an interface card. Finally,
> > > RFC4291 says the following:
> > >
> > >   "IPv6 addresses of all types are assigned to interfaces, not nodes.
> > >   An IPv6 unicast address refers to a single interface.  Since each
> > >   interface belongs to a single node, any of that node's interfaces'
> > >   unicast addresses may be used as an identifier for the node."
> > >
> > > From this text, we see that an IPv6 address may be used as an identifier for
> > > the node, which is exactly what a DUID is. And, an IPv6 address is unlike any
> > > of the existing DUID types, since by definition the address must be in the
> > > format specified by RFC4291. Hence, a new DUID type is requested.
> > >
> > > Fred
> > >
> > >> -----Original Message-----
> > >> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> > >> Sent: Thursday, January 14, 2021 8:19 AM
> > >> To: Bob Hinden <bob.hinden@gmail.com>
> > >> Cc: dhcwg <dhcwg@ietf.org>rg>; IPv6 List <ipv6@ietf.org>rg>; Dickson (US), Sean M <sean.m.dickson@boeing.com>
> > >> Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
> > >>
> > >> Bob, I have been offline until just now due to windstorms that knocked out power
> > >> and Internet access in the Seattle area over the past couple of days. I will reply to
> > >> your question shortly.
> > >>
> > >> Fred
> > >>
> > >>> -----Original Message-----
> > >>> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> > >>> Sent: Tuesday, January 12, 2021 4:43 PM
> > >>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > >>> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Ole Trøan <otroan@employees.org>rg>; 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,
> > >>>
> > >>>> 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
> > >>>>>> --------------------------------------------------------------------
> > >>>>
> > >>
> > >> _______________________________________________
> > >> dhcwg mailing list
> > >> dhcwg@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg