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

[Bob Hinden <[e-mail]>]

Fred,

> On Jan 15, 2021, at 12:25 PM, Templin (US), Fred L <[e-mail]> wrote:
> 
> 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.

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




> 
> 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
> 
>> -----Original Message-----
>> From: Bernie Volz (volz) [mailto:[e-mail]]
>> Sent: Friday, January 15, 2021 12:15 PM
>> To: Templin (US), Fred L <[e-mail]>; Bob Hinden <[e-mail]>
>> Cc: dhcwg <[e-mail]>; IPv6 List <[e-mail]>; Dickson (US), Sean M <[e-mail]>
>> Subject: RE: I-D Action: draft-templin-duid-ipv6-01.txt
>> 
>> 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 <[e-mail]> On Behalf Of Templin (US), Fred L
>> Sent: Friday, January 15, 2021 2:38 PM
>> To: Bob Hinden <[e-mail]>
>> Cc: dhcwg <[e-mail]>; IPv6 List <[e-mail]>; Dickson (US), Sean M <[e-mail]>
>> 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:
>> 
>> 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:[e-mail]] On Behalf Of Templin (US),
>>> Fred L
>>> Sent: Friday, January 15, 2021 10:57 AM
>>> To: Bob Hinden <[e-mail]>
>>> Cc: dhcwg <[e-mail]>; IPv6 List <[e-mail]>; Dickson (US),
>>> Sean M <[e-mail]>
>>> 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:[e-mail]] On Behalf Of Templin
>>>> (US), Fred L
>>>> Sent: Thursday, January 14, 2021 11:46 AM
>>>> To: Bob Hinden <[e-mail]>
>>>> Cc: dhcwg <[e-mail]>; IPv6 List <[e-mail]>; Dickson (US),
>>>> Sean M <[e-mail]>
>>>> Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action:
>>>> draft-templin-duid-ipv6-01.txt
>>>> 
>>>> Bob,
>>>> 
>>>>> -----Original Message-----
>>>>> From: Bob Hinden [mailto:[e-mail]]
>>>>> Sent: Thursday, January 14, 2021 10:44 AM
>>>>> To: Templin (US), Fred L <[e-mail]>
>>>>> Cc: Bob Hinden <[e-mail]>; dhcwg <[e-mail]>;
>>>>> IPv6 List <[e-mail]>; Dickson (US), Sean M
>>>>> <[e-mail]>
>>>>> 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 <[e-mail]> 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:[e-mail]] On Behalf Of
>>>>>>> Templin (US), Fred L
>>>>>>> Sent: Thursday, January 14, 2021 8:19 AM
>>>>>>> To: Bob Hinden <[e-mail]>
>>>>>>> Cc: dhcwg <[e-mail]>; IPv6 List <[e-mail]>; Dickson
>>>>>>> (US), Sean M <[e-mail]>
>>>>>>> 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:[e-mail]]
>>>>>>>> Sent: Tuesday, January 12, 2021 4:43 PM
>>>>>>>> To: Templin (US), Fred L <[e-mail]>
>>>>>>>> Cc: Bob Hinden <[e-mail]>; Ole Trøan
>>>>>>>> <[e-mail]>; dhcwg <[e-mail]>; IPv6 List
>>>>>>> <[e-mail]>;
>>>>>>>> Dickson (US), Sean M <[e-mail]>
>>>>>>>> Subject: Re: I-D Action: draft-templin-duid-ipv6-01.txt
>>>>>>>> 
>>>>>>>> Fred,
>>>>>>>> 
>>>>>>>>> On Jan 12, 2021, at 3:05 PM, Templin (US), Fred L <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> Ole,
>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [e-mail] [mailto:[e-mail]]
>>>>>>>>>> Sent: Tuesday, January 12, 2021 1:34 PM
>>>>>>>>>> To: Templin (US), Fred L <[e-mail]>
>>>>>>>>>> Cc: Bob Hinden <[e-mail]>; dhcwg
>>>>>>>>>> <[e-mail]>; 6man WG <[e-mail]>; Dickson (US),
>>>>>>>>>> Sean M <[e-mail]>
>>>>>>>>>> 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 <[e-mail]> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Bob, please see my subsequent reply to Eric Vyncke that discusses motivation:
>>>>>>>>>>> 
>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ipv6/yOfWHSnt36Hvjr44
>>>>>>>>>>> OERjK0OFvhw/
>>>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>>> Sent: Tuesday, January 12, 2021 10:22 AM
>>>>>>>>>>>> To: Templin (US), Fred L <[e-mail]>
>>>>>>>>>>>> Cc: Bob Hinden <[e-mail]>; Mark Smith
>>>>>>>>>>>> <[e-mail]>; dhcwg <[e-mail]>; IPv6
>>>>>>>>>>>> List <[e-mail]>; Dickson (US), Sean M
>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>> 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 <[e-mail]> 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:[e-mail]]
>>>>>>>>>>>>>> Sent: Monday, January 11, 2021 5:32 PM
>>>>>>>>>>>>>> To: Templin (US), Fred L <[e-mail]>
>>>>>>>>>>>>>> Cc: [e-mail]; dhcwg <[e-mail]>; Dickson (US),
>>>>>>>>>>>>>> Sean M <[e-mail]>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> <[e-mail]> 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:[e-mail]] On Behalf Of
>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>> Sent: Monday, January 11, 2021 10:21 AM
>>>>>>>>>>>>>>> To: [e-mail]
>>>>>>>>>>>>>>> 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-ipv
>>>>>>>>>>>>>>> 6/
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 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-dui
>>>>>>>>>>>>>>> d-ipv6-01
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> A diff from the previous version is available at:
>>>>>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-templin-duid-ip
>>>>>>>>>>>>>>> v6-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 [e-mail]
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> [e-mail] Administrative Requests:
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>>>>>>> -------------------------------------------------------
>>>>>>>>>>>>>>> -------------
>>>>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>>>>> ----------- IETF IPv6 working group mailing list
>>>>>>>>>>>>> [e-mail] Administrative Requests:
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>>>>> -----------
>>>>>>>>>>> 
>>>>>>>>>>> -----------------------------------------------------------
>>>>>>>>>>> --------- IETF IPv6 working group mailing list
>>>>>>>>>>> [e-mail] Administrative Requests:
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>>> -----------------------------------------------------------
>>>>>>>>>>> ---------
>>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> dhcwg mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>> 
>>>> _______________________________________________
>>>> dhcwg mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>> _______________________________________________
>>> dhcwg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------