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

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 11 Jan 2021 18:46:35 +0000

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Jan 2021 12:32:24 +1100

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:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 12 Jan 2021 13:49:36 +0000

<without any hat>

Hello Fred,

Just wondering how would this new DUID could be used when several interfaces sharing the same DUID will request some address(es)/prefix(es) over DHCPv6 ?

If you allow me to guess your use case, then would DUID type based on the private enterprise number (FAA and EASA have ones) could be used ? This would be simpler than requesting a new DUID type

Hope this helps,

Regards

-éric

</without any hat>

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of "Templin (US), Fred L" <[email-masked]>
Date: Monday, 11 January 2021 at 19:47
To: "[email-masked]" <[email-masked]>, dhcwg <[email-masked]>
Cc: "Dickson (US), Sean M" <[email-masked]>
Subject: FW: I-D Action: draft-templin-duid-ipv6-01.txt

    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

    Abstract:

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 12 Jan 2021 16:42:07 +0000

Eric, see below:

> From: Eric Vyncke (evyncke) [mailto:[email-masked]]
> Sent: Tuesday, January 12, 2021 5:50 AM
> To: Templin (US), Fred L <[email-masked]>; [email-masked]; dhcwg <[email-masked]>
> Cc: Dickson (US), Sean M <[email-masked]>
> Subject: Re: I-D Action: draft-templin-duid-ipv6-01.txt
> 
> <without any hat>
> 
> Hello Fred,
> 

I think this may have been addressed in my response to Mark, but the intention is
that an IPv6 address that is independent of any of the node's physical interfaces
and that provides an identity for the node is the address that would go into the
DUID. [RFC7401][draft-ietf-drip-rid] are two examples where a valid IPv6 address
is generated and intended to provide an interface-independent, unique and long
lived identity for the node. Other examples may be defined in the future as well.

> If you allow me to guess your use case, then would DUID type based on the private enterprise number (FAA and EASA have ones)
> could be used ? This would be simpler than requesting a new DUID type

I was actually thinking that DUID-UUID would be a candidate surrogate DUID because
the body is exactly 128bits the same as for IPv6 addresses. But, by definition, UUIDs
are *not* IPv6 addresses since they do not observe the [RFC4291] address architecture.
Per your suggestion, a private enterprise number could be gotten (AERO also already
has one) and then use DUID-EN instead. But, then there would not be a standards
track specification guaranteeing that the holder of the private enterprise number
would consistently and forever always apply IPv6 address architecture semantics to
their application of the private enterprise number.

Hence, the proposal for DUID-V6ADDR. Or, if folks would prefer a different name
I could imagine alternatives such as DUID-IN6, DUID-IPV6, etc. Any preferences?

Thanks - Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 12 Jan 2021 17:08:33 +0000

To add a bit more to my last couple of messages, RFC4291 says the following
about IPv6 addresses:

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

What I am proposing honors this fact because the IPv6 address
that would appear in the DUID-V6ADDR must also be assigned to
an interface of the node, and a loopback or some other manner
of virtual interface qualifies. I will update the draft to make sure
this is made clear.

Thanks - Fred

> From: dhcwg [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Tuesday, January 12, 2021 8:42 AM
> To: Eric Vyncke (evyncke) <[email-masked]>; [email-masked]; dhcwg <[email-masked]>
> Subject: Re: [dhcwg] I-D Action: draft-templin-duid-ipv6-01.txt
> 
> Eric, see below:
> 
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Antonio Escalera <[email-masked]>
Date: Tue, 12 Jan 2021 13:46:34 -0500

Ahhhh, see this makes it more clear. So your idea is akin to a hostname
except implemented over IPv6. I think making it clear that the intention is
to assign the IP address to a loopback interface would make the draft more
acceptable.

I really like this idea. Thanks for clearing that up.

I primarily work on clouds, this would be especially useful for containers
in environments where multiple networking interfaces are exposed. Now to
implement a CNI over ipv6...

Best,
Antonio

On Tue, Jan 12, 2021, 11:42 AM Templin (US), Fred L <
[email-masked]> wrote:

> > Just wondering how would this new DUID could be used when several
> interfaces sharing the same DUID will request some
> > address(es)/prefix(es) over DHCPv6 ?
>
> > If you allow me to guess your use case, then would DUID type based on
> the private enterprise number (FAA and EASA have ones)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 12 Jan 2021 21:41:18 +0000

BTW: If you used DUID-EN, you could easily do what we already do with the DUID:

For AERO's Enterprise-ID, you can in the identifier field add 2-bytes of type to start followed by the value. This would let AERO use many different DUID types under its enterprise number.

But this does require the Enterprise Number owner to assure that they always use the 2-bytes type in the future and have their own "IANA" to manage it.

(Organizations tend to be bad at managing vendor spaces as I only know too well - cost saving measures have usually meant that people assigned to manage these kinds of spaces are cut or moved elsewhere.)

It will be good too see an updated version which provides motivation for a new type - with a clear explanation of why none of the existing types are appropriate. Also, you may want to consider text that says something like only use this new type for these specific usages, otherwise you MUST use one of the other types.

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of Templin (US), Fred L
Sent: Tuesday, January 12, 2021 11:42 AM
To: Eric Vyncke (evyncke) <[email-masked]>; [email-masked]; dhcwg <[email-masked]>
Cc: Dickson (US), Sean M <[email-masked]>
Subject: Re: [dhcwg] I-D Action: draft-templin-duid-ipv6-01.txt

> address(es)/prefix(es) over DHCPv6 ?

I think this may have been addressed in my response to Mark, but the intention is that an IPv6 address that is independent of any of the node's physical interfaces and that provides an identity for the node is the address that would go into the DUID. [RFC7401][draft-ietf-drip-rid] are two examples where a valid IPv6 address is generated and intended to provide an interface-independent, unique and long lived identity for the node. Other examples may be defined in the future as well.

> the private enterprise number (FAA and EASA have ones) could be used ? 
> This would be simpler than requesting a new DUID type

I was actually thinking that DUID-UUID would be a candidate surrogate DUID because the body is exactly 128bits the same as for IPv6 addresses. But, by definition, UUIDs are *not* IPv6 addresses since they do not observe the [RFC4291] address architecture.
Per your suggestion, a private enterprise number could be gotten (AERO also already has one) and then use DUID-EN instead. But, then there would not be a standards track specification guaranteeing that the holder of the private enterprise number would consistently and forever always apply IPv6 address architecture semantics to their application of the private enterprise number.

Hence, the proposal for DUID-V6ADDR. Or, if folks would prefer a different name I could imagine alternatives such as DUID-IN6, DUID-IPV6, etc. Any preferences?

Thanks - Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 12 Jan 2021 22:47:26 +0000

Hi Bernie,

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Tuesday, January 12, 2021 1:41 PM
> To: Templin (US), Fred L <[email-masked]>; Eric Vyncke (evyncke) <[email-masked]>; [email-masked]; dhcwg
> <[email-masked]>
> Subject: RE: I-D Action: draft-templin-duid-ipv6-01.txt
> 
> 
> For AERO's Enterprise-ID, you can in the identifier field add 2-bytes of type to start followed by the value. This would let AERO use
> many different DUID types under its enterprise number.

FYI, here is the IANA Private Enterprise Number (PEN) code I was referring to
when I (incorrectly) cited AERO:

45282
  LinkUp Networks
    Fred L. Templin
      fltemplin&acm.org

But, that value was not established by any standards action, and indeed it is a
simple matter for anyone to obtain a PEN code from IANA outside the auspices
of IETF standards. It would therefore seem like an enormous DOWNREF to
entrust a random PEN code with carrying the entire global IPv6 address space
that mature IETF standards will depend on. DUID-EN also has the disadvantage
that a 6-byte "type code" preamble is always present, which is clumsy at best
for a function intended to become mainstream in the future.
 
> (Organizations tend to be bad at managing vendor spaces as I only know too well - cost saving measures have usually meant that
> people assigned to manage these kinds of spaces are cut or moved elsewhere.)

Right; I don't think our standards should rely on random organizations that procure
a PEN code to be dependable stewards of the space.

> It will be good too see an updated version which provides motivation for a new type - with a clear explanation of why none of the
> existing types are appropriate. Also, you may want to consider text that says something like only use this new type for these specific
> usages, otherwise you MUST use one of the other types.

Working on it.

Thanks - Fred

> I think this may have been addressed in my response to Mark, but the intention is that an IPv6 address that is independent of any of
> the node's physical interfaces and that provides an identity for the node is the address that would go into the DUID. [RFC7401][draft-
> ietf-drip-rid] are two examples where a valid IPv6 address is generated and intended to provide an interface-independent, unique
> and long lived identity for the node. Other examples may be defined in the future as well.
> 
> I was actually thinking that DUID-UUID would be a candidate surrogate DUID because the body is exactly 128bits the same as for IPv6
> addresses. But, by definition, UUIDs are *not* IPv6 addresses since they do not observe the [RFC4291] address architecture.
> Per your suggestion, a private enterprise number could be gotten (AERO also already has one) and then use DUID-EN instead. But,
> then there would not be a standards track specification guaranteeing that the holder of the private enterprise number would
> consistently and forever always apply IPv6 address architecture semantics to their application of the private enterprise number.
>