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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 12 January 2021 18:40 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 D41D53A0F0F; Tue, 12 Jan 2021 10:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 LeaZ9wnRR_Xh; Tue, 12 Jan 2021 10:40:25 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 575AB3A0F09; Tue, 12 Jan 2021 10:40:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 10CIeMQT006752; Tue, 12 Jan 2021 13:40:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1610476823; bh=pY8poFo9AqmxpTbVsFxwxt7Y59A0Po1YyigVOqF9ysA=; h=From:To:CC:Subject:Date:From; b=dydywj5avTHzScVPfl3NHo9ozHlKAwd4cGNWoWltbbXkKRdKi+S+IhVx8D0k9gaVs zd64YoVhSbFyKZOgQ4U8RWSXeE3nrA/GjgAbYDxChLMd/7F7LTDkc6GMC6kYlkRvdm of4yUcRR6q9YAzg0Mxb1mMe2ayo0Tr78dYj/Vu9oz4K7z7FyHOBtrdB+D1kAG2Ou9R kSUkrCIleQbDr6IvIwRIUDhtGloHHK8XYUV6No+l+889q73NhkxnbGtYtpej6rlZUz /TNxh8n+grAA52SUjWJWXqGWRSozoJfDn6Rvn23L+tk1Esnk/iQ3IPf1QFGLGadO2f 72i5we7zcMzqg==
Received: from XCH16-02-11.nos.boeing.com (xch16-02-11.nos.boeing.com [144.115.66.77]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 10CIeCJ2006566 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 12 Jan 2021 13:40:12 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-02-11.nos.boeing.com (144.115.66.77) 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 10:40:11 -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 10:40:11 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: 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
Thread-Topic: I-D Action: draft-templin-duid-ipv6-01.txt
Thread-Index: AdbpEYB9fbonJRBASxmKuF8hagiraA==
Date: Tue, 12 Jan 2021 18:40:10 +0000
Message-ID: <f6ae99d24c9447399bd3b2e3b3c029c4@boeing.com>
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: 1F853D25F4C572BF27846744775850DB6530F38A8E319D5666AEBE7515504C922000: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/hKp5l-6pbgZKnw0HSEWNSsW7_a8>
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 18:40:28 -0000

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>om>; Mark Smith <markzzzsmith@gmail.com>om>; dhcwg <dhcwg@ietf.org>rg>; IPv6 List
> <ipv6@ietf.org>rg>; 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>rg>; 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
> > --------------------------------------------------------------------