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

["Templin (US), Fred L" <[e-mail]>]

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

> -----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
> --------------------------------------------------------------------