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

[Bob Hinden <[e-mail]>]

Fred,

> On Jan 12, 2021, at 10:40 AM, 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/yOfWHSnt36Hvjr44OERjK0OFvhw/
> https://mailarchive.ietf.org/arch/msg/dhcwg/YZq_aPf1C82ZFT_bTdXOXVXTPW0/

Sorry, I didn’t see an answer is why is this needed.  At the moment I don’t see a justification for this draft.

Bob

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