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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 12 January 2021 23:06 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F243A13C7; Tue, 12 Jan 2021 15:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49iN0XNY1hif; Tue, 12 Jan 2021 15:06:04 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C20D3A13C5; Tue, 12 Jan 2021 15:06:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 10CN61Cj014367; Tue, 12 Jan 2021 18:06:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1610492763; bh=uwcQS6cJ+7VgQoNbnEkbyc/t5teplvc4QvJQUiBmqHQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Rv0EaWipp563+zXbSsGTvAnhriomP7f0v1L5am3nbQARpzyQ8k6b/J7EkOFps2oTR FEqmzIv/vade+NqSeNLC9mwLqwGs9tdfNaZYsGBssCnKWTz+kMLVfeOS3Rl6S1LS4x Yh/GfmCpZqrlSeYQ4Rq9Dhe1Yswa6O8rNxRdyAoZMT9Toowkmyjp7gT5NUKIGYuwr+ 1OqFBbho5KiLxOKuQNcQmMx0B6MboNp3XE2nhcdNO0+S8ij83Hud7v62wI3xxPdgbd n5NjxSKenw+xXc35gw583a/mv88sqNBfL+jGbSuBWxx84vnnzSJ7ujSZb0C1Qh3X7n a7LhFbTZMEfvQ==
Received: from XCH16-02-07.nos.boeing.com (xch16-02-07.nos.boeing.com [144.115.66.71]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 10CN5scJ014203 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 12 Jan 2021 18:05:55 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-02-07.nos.boeing.com (144.115.66.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 12 Jan 2021 15:05:53 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 12 Jan 2021 15:05:53 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "otroan@employees.org" <otroan@employees.org>
CC: Bob Hinden <bob.hinden@gmail.com>, dhcwg <dhcwg@ietf.org>, 6man WG <ipv6@ietf.org>, "Dickson (US), Sean M" <sean.m.dickson@boeing.com>
Subject: RE: [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
Thread-Topic: [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
Thread-Index: AdbpEYB9fbonJRBASxmKuF8hagiraAAXD8qAAA3EBnA=
Date: Tue, 12 Jan 2021 23:05:53 +0000
Message-ID: <c938d77ed2b347da8dc23e1a8190b709@boeing.com>
References: <f6ae99d24c9447399bd3b2e3b3c029c4@boeing.com> <74460CA0-A839-4179-A162-6946456591C7@employees.org>
In-Reply-To: <74460CA0-A839-4179-A162-6946456591C7@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: E1FF11402CAEA61987AA9F3888BA34EB81361AD4A96FE0F544D7C98A50C0EC502000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vJqTEc5LOG0AucdcdcDsrj4xdVA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jan 2021 23:06:07 -0000

Ole,

> -----Original Message-----
> From: otroan@employees.org [mailto:otroan@employees.org]
> Sent: Tuesday, January 12, 2021 1:34 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>; dhcwg <dhcwg@ietf.org>; 6man WG <ipv6@ietf.org>; Dickson (US), Sean M
> <sean.m.dickson@boeing.com>
> 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.

> 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 <Fred.L.Templin@boeing.com> 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:bob.hinden@gmail.com]
> >> Sent: Tuesday, January 12, 2021 10:22 AM
> >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >> Cc: Bob Hinden <bob.hinden@gmail.com>; Mark Smith <markzzzsmith@gmail.com>; dhcwg <dhcwg@ietf.org>; IPv6 List
> >> <ipv6@ietf.org>; Dickson (US), Sean M <sean.m.dickson@boeing.com>
> >> 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 <Fred.L.Templin@boeing.com> 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:markzzzsmith@gmail.com]
> >>>> Sent: Monday, January 11, 2021 5:32 PM
> >>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >>>> Cc: ipv6@ietf.org; dhcwg <dhcwg@ietf.org>; Dickson (US), Sean M <sean.m.dickson@boeing.com>
> >>>> 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
> >>>> <Fred.L.Templin@boeing.com> 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:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> >>>>> Sent: Monday, January 11, 2021 10:21 AM
> >>>>> To: i-d-announce@ietf.org
> >>>>> 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
> >>>>> I-D-Announce@ietf.org
> >>>>> 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
> >>>>> ipv6@ietf.org
> >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>> --------------------------------------------------------------------
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------