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

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 15 Jan 2021 19:38:07 +0000

Another high-level point. People seem to forget that this all got started with
a *draft*, and the draft does go into detailed discussion that many of the
questioners seem not to have read:

https://www.ietf.org/archive/id/draft-templin-duid-ipv6-01.txt

The draft does discuss the relation to DUID-UUID at length. But, if people
are fine with my putting a non-UUID 128-bit quantity in a DUID-UUID that
is cool and I'm happy to do it - just let me know if that is what you want.

Fred

> -----Original Message-----
> From: dhcwg [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Friday, January 15, 2021 10:57 AM
> To: Bob Hinden <[email-masked]>
> Cc: dhcwg <[email-masked]>; IPv6 List <[email-masked]>; Dickson (US), Sean M <[email-masked]>
> Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
> 
> 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:[email-masked]] On Behalf Of Templin (US), Fred L
> > Sent: Thursday, January 14, 2021 11:46 AM
> > To: Bob Hinden <[email-masked]>
> > Cc: dhcwg <[email-masked]>; IPv6 List <[email-masked]>; Dickson (US), Sean M <[email-masked]>
> > Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
> >
> > Bob,
> >
> > > -----Original Message-----
> > > From: Bob Hinden [mailto:[email-masked]]
> > > Sent: Thursday, January 14, 2021 10:44 AM
> > > To: Templin (US), Fred L <[email-masked]>
> > > Cc: Bob Hinden <[email-masked]>; dhcwg <[email-masked]>; IPv6 List <[email-masked]>; Dickson (US), Sean M
> > > <[email-masked]>
> > > 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 <[email-masked]> 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:[email-masked]] On Behalf Of Templin (US), Fred L
> > > >> Sent: Thursday, January 14, 2021 8:19 AM
> > > >> To: Bob Hinden <[email-masked]>
> > > >> Cc: dhcwg <[email-masked]>; IPv6 List <[email-masked]>; Dickson (US), Sean M <[email-masked]>
> > > >> 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:[email-masked]]
> > > >>> Sent: Tuesday, January 12, 2021 4:43 PM
> > > >>> To: Templin (US), Fred L <[email-masked]>
> > > >>> Cc: Bob Hinden <[email-masked]>; Ole Trøan <[email-masked]>; dhcwg <[email-masked]>; IPv6 List
> > > >> <[email-masked]>;
> > > >>> Dickson (US), Sean M <[email-masked]>
> > > >>> Subject: Re: I-D Action: draft-templin-duid-ipv6-01.txt
> > > >>>
> > > >>> Fred,
> > > >>>
> > > >>>> On Jan 12, 2021, at 3:05 PM, Templin (US), Fred L <[email-masked]> wrote:
> > > >>>>
> > > >>>> Ole,
> > > >>>>
> > > >>>>> -----Original Message-----
> > > >>>>> From: [email-masked] [mailto:[email-masked]]
> > > >>>>> Sent: Tuesday, January 12, 2021 1:34 PM
> > > >>>>> To: Templin (US), Fred L <[email-masked]>
> > > >>>>> Cc: Bob Hinden <[email-masked]>; dhcwg <[email-masked]>; 6man WG <[email-masked]>; Dickson (US), Sean M
> > > >>>>> <[email-masked]>
> > > >>>>> 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 <[email-masked]> 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:[email-masked]]
> > > >>>>>>> Sent: Tuesday, January 12, 2021 10:22 AM
> > > >>>>>>> To: Templin (US), Fred L <[email-masked]>
> > > >>>>>>> Cc: Bob Hinden <[email-masked]>; Mark Smith <[email-masked]>; dhcwg <[email-masked]>; IPv6 List
> > > >>>>>>> <[email-masked]>; Dickson (US), Sean M <[email-masked]>
> > > >>>>>>> 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 <[email-masked]> 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:[email-masked]]
> > > >>>>>>>>> Sent: Monday, January 11, 2021 5:32 PM
> > > >>>>>>>>> To: Templin (US), Fred L <[email-masked]>
> > > >>>>>>>>> Cc: [email-masked]; dhcwg <[email-masked]>; Dickson (US), Sean M <[email-masked]>
> > > >>>>>>>>> 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
> > > >>>>>>>>> <[email-masked]> 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:[email-masked]] On Behalf Of [email-masked]
> > > >>>>>>>>>> Sent: Monday, January 11, 2021 10:21 AM
> > > >>>>>>>>>> To: [email-masked]
> > > >>>>>>>>>> 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
> > > >>>>>>>>>> [email-masked]
> > > >>>>>>>>>> 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
> > > >>>>>>>>>> [email-masked]
> > > >>>>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > >>>>>>>>>> --------------------------------------------------------------------
> > > >>>>>>>> --------------------------------------------------------------------
> > > >>>>>>>> IETF IPv6 working group mailing list
> > > >>>>>>>> [email-masked]
> > > >>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > >>>>>>>> --------------------------------------------------------------------
> > > >>>>>>
> > > >>>>>> --------------------------------------------------------------------
> > > >>>>>> IETF IPv6 working group mailing list
> > > >>>>>> [email-masked]
> > > >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > >>>>>> --------------------------------------------------------------------
> > > >>>>
> > > >>
> > > >> _______________________________________________
> > > >> dhcwg mailing list
> > > >> [email-masked]
> > > >> https://www.ietf.org/mailman/listinfo/dhcwg
> >
> > _______________________________________________
> > dhcwg mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 15 Jan 2021 20:14:50 +0000

Hi Fred:

As I've tried to point out, what I find in the draft is still insufficient. Comparing against just the DUID-UUID is not sufficient.

You need to explain why the existing forms (-LL, -LLT, -UUID) are insufficient; not just propose well I'll put my v6 address into the DUID-UUID as it is also 128 bits (but prefer not to overload as doesn't match UUID format). That's why you MUST NOT use DUID-UUID for your proposes (placing the IPv6 address into it).

As an example, look at https://tools.ietf.org/html/rfc6355#section-2 as that clearly provides details as why DUID-UUID has benefits over the 3 other formats at the time as why it should be a standardized format. You need material such as this. Without it, I would strongly recommend against this work because there is no rational for needing it (other than "hey I like this better.").

If you don't want to provide these arguments, then I highly recommend you use the DUID-EN under the AERO or whatever enterprise id you want to specify.

- Bernie

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Templin (US), Fred L
Sent: Friday, January 15, 2021 2:38 PM
To: Bob Hinden <[email-masked]>
Cc: dhcwg <[email-masked]>; IPv6 List <[email-masked]>; Dickson (US), Sean M <[email-masked]>
Subject: Re: I-D Action: draft-templin-duid-ipv6-01.txt

Another high-level point. People seem to forget that this all got started with a *draft*, and the draft does go into detailed discussion that many of the questioners seem not to have read:

The draft does discuss the relation to DUID-UUID at length. But, if people are fine with my putting a non-UUID 128-bit quantity in a DUID-UUID that is cool and I'm happy to do it - just let me know if that is what you want.

Fred

> 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
> 
> > > Cc: Bob Hinden <[email-masked]>; dhcwg <[email-masked]>; 
> > > IPv6 List <[email-masked]>; Dickson (US), Sean M 
> > > > 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.
> > >
> > 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:
> > >
> > > > 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.
> > >
> > [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.
> >
> > 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,
> > > > 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
> > > >
> > > >> 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
> > > >>
> > > >>> Cc: Bob Hinden <[email-masked]>; Ole Trøan 
> > > >>> <[email-masked]>; dhcwg <[email-masked]>; IPv6 List
> > > >> <[email-masked]>;
> > > >>>>> Cc: Bob Hinden <[email-masked]>; dhcwg 
> > > >>>>> <[email-masked]>; 6man WG <[email-masked]>; Dickson (US), 
> > > >>>>> Sean M <[email-masked]>
> > > >>>>>  "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
> > > >>>>>
> > > >>>>>> Per your comment, perhaps a new section on "motivation" 
> > > >>>>>> could be added to the draft?
> > > >>>>>>
> > > >>>>>> Thanks - Fred
> > > >>>>>>
> > > >>>>>>> Cc: Bob Hinden <[email-masked]>; Mark Smith 
> > > >>>>>>> <[email-masked]>; dhcwg <[email-masked]>; IPv6 
> > > >>>>>>> List <[email-masked]>; Dickson (US), Sean M 
> > > >>>>>>> "I don't understand what problem this is trying to solve 
> > > >>>>>>> or see any benefits of it. What is wrong with existing DUIDs?”
> > > >>>>>>>
> > > >>>>>>>> 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
> > > >>>>>>>>
> > > >>>>>>>>> I don't understand what problem this is trying to solve 
> > > >>>>>>>>> or see any benefits of it. What is wrong with existing DUIDs?
> > > >>>>>>>>>
> > > >>>>>>>>> "...  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.,
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> 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."
> > > >>>>>>>>>
> > > >>>>>>>>> DHCPv6 Unique Identifiers outside of the DHCP protocol 
> > > >>>>>>>>> would be an abuse of a DUID.
> > > >>>>>>>>>
> > > >>>>>>>>> Regards,
> > > >>>>>>>>> Mark.
> > > >>>>>>>>>
> > > >>>>>>>>>> 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.
> > > >>>>>>>>>>
> > > >>>>>>>>>> From: I-D-Announce 
> > > >>>>>>>>>> [mailto:[email-masked]] On Behalf Of 
> > > >>>>>>>>>> [email-masked]
> > > >>>>>>>>>> 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.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> 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.
> > > >>>>>>>>>>
> > > >>>>>>>>>> I-D-Announce mailing list [email-masked] 
> > > >>>>>>>>>> Internet-Draft directories: 
> > > >>>>>>>>>> http://www.ietf.org/shadow.html or 
> > > >>>>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >>>>>>>>>>
> > > >>>>>>>>>> -------------------------------------------------------
> > > >>>>>>>>>> ------------- IETF IPv6 working group mailing list 
> > > >>>>>>>>>> [email-masked] Administrative Requests: 
> > > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
> > > >>>>>>>> ---------------------------------------------------------
> > > >>>>>>>> ----------- IETF IPv6 working group mailing list 
> > > >>>>>>>> [email-masked] Administrative Requests: 
> > > >>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
> > > >>>>>> -----------------------------------------------------------
> > > >>>>>> --------- IETF IPv6 working group mailing list 
> > > >>>>>> [email-masked] Administrative Requests: 
> > > >>>>>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 15 Jan 2021 20:25:53 +0000

Bernie, I actually have a -02 draft version started and hinted to you that I was
"working on it", but then Bob sent a message that suggested list discussion
before posting a new draft. So, I responded to Bob's question and am waiting
for his rejoinder.

Again, if people want me to stick non-UUIDs in the DUID-UUID I am fine with
doing that. But, it would not be my first choice. And, using DUID-EN with some
arbitrary PEN code to encode the entire global IPv6 unicast address space would
IMHO be an unacceptable DOWNREF.

Fred

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Friday, January 15, 2021 12:15 PM
> To: Templin (US), Fred L <[email-masked]>; Bob Hinden <[email-masked]>
> Subject: RE: I-D Action: draft-templin-duid-ipv6-01.txt
> 
> Hi Fred:
> 
> You need to explain why the existing forms (-LL, -LLT, -UUID) are insufficient; not just propose well I'll put my v6 address into the
> DUID-UUID as it is also 128 bits (but prefer not to overload as doesn't match UUID format). That's why you MUST NOT use DUID-UUID
> for your proposes (placing the IPv6 address into it).
> 
> As an example, look at https://tools.ietf.org/html/rfc6355#section-2 as that clearly provides details as why DUID-UUID has benefits
> over the 3 other formats at the time as why it should be a standardized format. You need material such as this. Without it, I would
> strongly recommend against this work because there is no rational for needing it (other than "hey I like this better.").
> 
> Another high-level point. People seem to forget that this all got started with a *draft*, and the draft does go into detailed discussion
> that many of the questioners seem not to have read:
> 
> The draft does discuss the relation to DUID-UUID at length. But, if people are fine with my putting a non-UUID 128-bit quantity in a
> DUID-UUID that is cool and I'm happy to do it - just let me know if that is what you want.
> 
> Fred
> 
> > > > > 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.
> > > >
> > > > >>>>>>>> [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.
> > > > >>>>>>>>
> > > > >>>>>>>>>> -------------
> > > > >>>>>>>> -----------
> > > > >>>>>> ---------

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Jan 2021 15:30:40 -0500

On Jan 15, 2021, at 3:25 PM, Templin (US), Fred L <[email-masked]> wrote:
> using DUID-EN with some

You said this before. I don’t understand what this means. DUID-EN is in a standards track RFC. How is this a DOWNREF? And why use an arbitrary enterprise number?

---

From: Bob Hinden <[email-masked]>
Date: Fri, 15 Jan 2021 13:09:07 -0800

Fred,

> On Jan 15, 2021, at 12:25 PM, Templin (US), Fred L <[email-masked]> wrote:
> 

As far as I can tell, I and several other people have asked you why you want to to use an IPv6 address as a DUID as opposed to an existing DUID, and none of us have seen an answer.   It seems like a straight forward question.

Bernie’s suggestion to use a DUID-EN seems good to me.

Bob

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 15 Jan 2021 21:18:30 +0000

Fred

> Sent: Friday, January 15, 2021 1:09 PM
> Cc: Bob Hinden <[email-masked]>; Bernie Volz (volz) <[email-masked]>; dhcwg <[email-masked]>; IPv6 List <[email-masked]>;
> As far as I can tell, I and several other people have asked you why you want to to use an IPv6 address as a DUID as opposed to an
> existing DUID, and none of us have seen an answer.   It seems like a straight forward question.
> 
> >> If you don't want to provide these arguments, then I highly recommend you use the DUID-EN under the AERO or whatever
> enterprise
> >> id you want to specify.
> >>
> >> - Bernie
> >>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 15 Jan 2021 13:22:54 -0800

Fred,

> On Jan 15, 2021, at 1:18 PM, Templin (US), Fred L <[email-masked]> wrote:
> 

Perhaps this is true, but this does not answer why you are proposing it in your draft, nor why you can’t use one of the current DUID approaches.

Bob

---

From: Simon Hobson <[email-masked]>
Date: Sat, 16 Jan 2021 11:57:49 +0000

> could present an unacceptable privacy exposure.

Please don't take this as a personal attack, it's intended to (try to) be helpful.

There is a disconnect between the question you were asked, and the question you have answered. It's sounding very much like the interviews where the interviewer is asking a question, but the politician has decided one the different question they want to answer - and no matter how many times the interviewer tries to get the question answered, the politician persists in answering their different choice of question.
I sense a frustration on both sides : you perceive that you keep being asked a question you've already answered; other perceive that you are refusing to answer it; while the reality is that there's been a misunderstanding that leads to the perceptions remaining.

The question was : "why can't one of the existing methods be used ?"
The question you have answered is : "what allows other types to be created ?"

As others have been trying to say, just because you **can** doesn't mean that you **should**. So far you've been saying "we can do this", but you've given no indication of "why" anyone should do that. You need to document specific use cases where your ID works, but an existing ID type cannot be used - until you do that, the question will remain as to "why not use something that's already defined ?"

And both Bernie and Bob have given considerable detail as to why your suggestion might not be (note, "might not be", not "is not") a suitable identifier - i.e. points that do need addressing if the idea is to be taken seriously.

So, as I see it :
You need to say **why** existing types are unsuitable for the use cases you have in mind.
Clearly articulate what those use cases are.
Address the technical issues (mostly around lifetime and guarantee of uniqueness) that have been raised.

Simon