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

"Bernie Volz (volz)" <volz@cisco.com> Fri, 15 January 2021 15:50 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AE63A0B97; Fri, 15 Jan 2021 07:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=R5nyEgB+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nAgT2uCQ
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 91-fxDZlemx3; Fri, 15 Jan 2021 07:50:20 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5ACF3A0B1F; Fri, 15 Jan 2021 07:50:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8240; q=dns/txt; s=iport; t=1610725820; x=1611935420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+yd0o34fouCIkfrE3CcSztJuRMZukmalMq4B/O68NLo=; b=R5nyEgB+xvigL+J7kR4uOGvLTO7LfcGuKCbvOPSYQ3HRjSMyrE3npBLN y48+jQEQjwd/IkcjTFMc5CEgKNoTvMcN4/RfiM/Djq/ZRRfGhVppFSHT+ YCN3SpjTqhz8VBmVYNVSnhOC3uZCdCVa2eZYkvtFvfpMIe8ymHzrdiq+z U=;
X-IronPort-AV: E=Sophos;i="5.79,349,1602547200"; d="scan'208";a="826093275"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jan 2021 15:49:54 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 10FFnsKB008515 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Jan 2021 15:49:54 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 15 Jan 2021 09:49:54 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 15 Jan 2021 09:49:54 -0600
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 15 Jan 2021 10:49:54 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oILZZndhl5oz4zHEfk/NiBTUKb/8l2rkyU7iGKssKs2VTOnEd5B0Wx+zXWKgkfScxCR8CQiiDRE/pXH4w2xzU9xDNkWvQz8K/kgR7WMtipVJo0xcIlYgFH0q5/cRECOKtZXLy+BgbPRssMSVD7VDClW3qfV3CLBzVL6Ib3oRKxbpqTXDDsQboBBHKC9WpziE3JVBFGgTcUqMJfDqOKMmSa+o9ycLfbReUulKiFaYwEp/vSxe+jVs+Atzu5HN3RKrDcQ0Co0CAxFiwPGYd97Hq5EYJcQe+dxhAHhpyy+1rq+q0rbc34sZHzDiLi6/EdJs0r5ll8DrcoqCzYQfmgr90w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+yd0o34fouCIkfrE3CcSztJuRMZukmalMq4B/O68NLo=; b=RrupffZV5hKhg/Qv453BUU/n6X7yXNTIxTi1JVer6Lq8+hDrOMdg9KxLyLDs8zd+2Bmdum3tB5hHzpqE1eP/ikFLaoHXrCJVsSbT3f2WUtUKNL5agO4THKzyVWr0NNMFr6IQkd3fEnwuDLtTjpvcZjEEAz1cdJpxGXH4Oov8ZvQaRvPKOD7bPlb0wPGajAy6OqoFGpsEbdtHdnGQ/inaPHRhdtE+6qMELx6UjMqSEXRCR3GDsVF6vJkS7B6esX0BiOuRb+/EA+azhsM7Hh1IX8X6/McCsXA6XJ6f4IOW30Vk7e58JkUv/r0cVKjZHNXfiI6HnXgAt8nMyriHE7Ub2w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+yd0o34fouCIkfrE3CcSztJuRMZukmalMq4B/O68NLo=; b=nAgT2uCQGSK2ibddAZw7IqdKiOjAEFYg3pIdT1BX5E2CpJxyRSD6thTzmSA/hXqCop0crBpw+4wRBE/QIEux0vnFnrFgm6guK58j21LB0MRSUg/sZd3SrCIp2L4+anYf9z+zAoIbKso0a2JFCw56g4PXSiUIrHCquqGkC/nw5hQ=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN6PR11MB1875.namprd11.prod.outlook.com (2603:10b6:404:104::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.8; Fri, 15 Jan 2021 15:49:52 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::651c:70ca:fdc4:25eb]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::651c:70ca:fdc4:25eb%3]) with mapi id 15.20.3763.012; Fri, 15 Jan 2021 15:49:52 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
CC: Simon Hobson <linux@thehobsons.co.uk>, Ted Lemon <mellon@fugue.com>, dhcwg <dhcwg@ietf.org>, IPv6 List <ipv6@ietf.org>
Thread-Topic: I-D Action: draft-templin-duid-ipv6-01.txt
Thread-Index: AdbrVAUq8ifd9On5SaGFHM0jDP097wAALijw
Date: Fri, 15 Jan 2021 15:49:52 +0000
Message-ID: <BN7PR11MB254732F11D3E50CE3DC01FE5CFA70@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <8933413edf714c70bf582f0c35101c2a@boeing.com>
In-Reply-To: <8933413edf714c70bf582f0c35101c2a@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: boeing.com; dkim=none (message not signed) header.d=none;boeing.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.69]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9e305b68-9893-42a1-7170-08d8b96d32d4
x-ms-traffictypediagnostic: BN6PR11MB1875:
x-microsoft-antispam-prvs: <BN6PR11MB18758B96B04962599FACA42CCFA70@BN6PR11MB1875.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: oIQLODMaKjd+hjdz+HlkYx8IV2iqWVtZ5VhxdPKO70aJB83iW0IESmbnRiL2aDLjWMxniUtbNqO1gahzvY6g4IVyP1DPjvMO41uEC9g/ZmFL8xM7WEMkpBdeYaNnlsHK8raY940z5Em2iugIfccgOERZDqOp2tO4O9x6DgE+gA9ilhlOBUgoOGL0ippFBDWqy8lz7o81XqDGUrjOWEWCSM0dSGhBYfRcza8yg8mzUdqjX31a5LvpSBDwnuQ39uxXXDb74GWSO72y10YbJLfV6qx3wlGn5h2F3RSjDS+Bm1CPuGF67iyLlTHEClmm9lgEmMgAJdhpUljrs96RGqbLzZU5BDNpMKnXswdEbG3Kvu4TczeB69nAGkDW/f1tqsgGcxv+TySZ5F6UELwjz+6S8hwldDUyFTlWaPVdem0EUj4VdS5yqOWU+C9+/sM0HkcRJ6uV3sCB7AOgnlysWGqSgg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(376002)(346002)(39860400002)(366004)(71200400001)(52536014)(54906003)(6506007)(6916009)(55016002)(86362001)(478600001)(4326008)(26005)(186003)(316002)(9686003)(8676002)(8936002)(76116006)(66476007)(2906002)(66446008)(64756008)(66556008)(53546011)(33656002)(66946007)(5660300002)(83380400001)(7696005)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: RznRNqs6dFWOeG9RCnjIAPRBNlC2KVftNGfJrQutEXW5t7/0aD/SFVEh77QgrLjXILClIV36YGGIp6Q89NtJ9sooWINhGgpVucqbO4JTYsp0lG+haAZt7H09kvEswME2tb2fraZkK1AqqzPGC3P39BL8YgtIMxq3kvFMPoDByNDLeygjUdVf/7WkjeOtRL5Q6fKM87aJUGucGG9bTxGJh+BDK3patBX+mqxcNfjuf91Pi4sEdigZlE6gF79Q0MQauZkpOQBvXsc6Ue9ZvvZCbSLeR87M+pWqTsmGujgbGtlxjiC1NCtEhLDAgErUeYDeYg8/RxA0KEzrTe7tnwIQpgOHY2q1FIcWsIesWP0CjN+hiHfIpoyYe3fGXwhNaowsyuo12w/pJfSsX/rBbo4z26j1hNa0eVMRV/1ZZosgjQ3TVMWV1wpz8eUvhx4R+LOxz8oKKa4/bLpxvrNxdV2QMoLAptiSd2leLeTogxEmJwFlkEQq4qVXtUcE4fczgF3gkcjFp7YuzWFaNE9L6Wlu2qxbzufplsl/UNtc05iDYgwRPQFv7uiuaiySuzcvULwKf54yepVqFJKjWabIcdc7d8kOxOXlXVZfoXB4Eg/5S9KbrA438SK22Wrz0HYygchnIVwcAa9YUB7DUKmIf3j0qH2G52XeVQIyJb4eBXUrieJjw9kdyvCoe1Ijolwa3DDr3T3KVQa4ERLqR1g/Fn2XmfGxyTpCIWiEbHG/JXxnt2X/9YXTrTGaBOl5KHpnc9zK8VmY/Cw5OCh/JhK84Numz1997oPZHDdexiRo/zaCyGKUZy6Tacm+Mn8xXBMVqlt24DEgYGpnlnPfZs7g7RHWfEXGs4l37RDX9meawmNFFS0se/+15ifjzxQHzaKES0B2pkzSdBuUbvW+Qj/QJEtiq4W/2ePKs2nsELU4IWoxWeurvldCiMr+XRMyRgbASYgWORrtoBhy0I1kcvYMlj0S4IlHN3C4IVz3a3DFEuZqr0k=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2547.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e305b68-9893-42a1-7170-08d8b96d32d4
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2021 15:49:52.6303 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2BJd1sxkMH5w3ZzymlwJEBKcnrY0wLrBO4yx8C2R7oBvif6ZG09p+VX14RjT+CMs
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1875
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/heqGPkl_N2TQ1cycRZDa9s4U5r8>
Subject: Re: [dhcwg] I-D Action: draft-templin-duid-ipv6-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2021 15:50:23 -0000

Fred:

You are clearly not answering our questions. As I said, put DUID-EN aside. Why are the others not usable. Under what conditions should a DHCP client implementer use DUID-V6ADDR (and under what conditions MUST NOT it be used).

There are clear reasons for having the various forms we do have and there are statements as to when a particular one must not be used.

We could have many more DUID types, but we don't because there have to be clear reasons to have a new type ... and for that you need to explain why the existing types CANNOT be used and thus a new type is REQUIRED. This is why the bar for defining a new type was Standards Actions - we wanted it to be very high so that it is fully clear as to when one type should be used over another.

For example, if you said well my interfaces have no "link-layer addresses", that would rule out DUID-LL and DUID-LLT. It does leave DUID-UUID (and DUID-EN - but we can put that aside). So, perhaps then there's a reason why DUID-UUID cannot be used (perhaps no storage in which to record this). This then would mean none of the (-LL, -LLT, -UUID) could work.

But just to say "hey, I have an idea to use this for a DUID" isn't sufficient without the details of why it is REQUIRED and none of the existing types can be used.

- Bernie

-----Original Message-----
From: Templin (US), Fred L <Fred.L.Templin@boeing.com> 
Sent: Friday, January 15, 2021 10:40 AM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: Simon Hobson <linux@thehobsons.co.uk>; Ted Lemon <mellon@fugue.com>; dhcwg <dhcwg@ietf.org>; IPv6 List <ipv6@ietf.org>
Subject: Re: I-D Action: draft-templin-duid-ipv6-01.txt

It is clear from these last three that people are not reading all of my responses; especially those in response to Bob Hinden's questions where the use case is clearly explained.
Perhaps you are hoping that by asking the same question over and over again I will give a different answer. Please go back and read *all* of the posts; it is not a good use for any of our time for me to repeat myself over and over again.

Fred

PS Bernie and Ted - I have already explained why DUID-EN was considered but found to be too cumbersome and a DOWNREF.

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]
> Sent: Friday, January 15, 2021 6:48 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Simon Hobson <linux@thehobsons.co.uk>; dhcwg <dhcwg@ietf.org>; 
> IPv6 List <ipv6@ietf.org>
> Subject: RE: [dhcwg] Re: I-D Action: draft-templin-duid-ipv6-01.txt
>
> Fred:
> 
> I agree with Simon.
> 
> You have not explained why you cannot use one of the existing methods 
> - even putting aside DUID-EN. Why can you not use DUID-LL, DUID-LLT, or DUID-UUID?
> 
> And, with DUID-EN, you can do whatever you want without anyone's input 
> - of course, whether that usage is a good idea is a separate question. 
> Yes, it may have a few additional bytes more than DUID-V6ADDR, but that hardly seems like a useful argument at this point as we still don't know why this is better than the existing DUID types for a STANDARDIZED type.
> 
> I still see no text in the 00 or 01 draft about why you need this over 
> the existing methods - i.e., why none of the existing methods will work.
> 
> The other thing about a standardized DUID is that you have to assure 
> it is not misused or misunderstood how it should be used. So, you need to be clear about when it MAY be used and when it MUST NOT be used.
> 
> - Bernie
> 
> -----Original Message-----
> From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Simon Hobson
> Sent: Friday, January 15, 2021 9:08 AM
> To: dhcwg <dhcwg@ietf.org>; IPv6 List <ipv6@ietf.org>
> Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: 
> draft-templin-duid-ipv6-01.txt
> 
> Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> >> No. I questioned the purpose of having an IPv6 address in something that’s supposed to be an opaque identifier.
> >
> > And, I said that if it were *truly* opaque to *all* examinations and 
> > references, then there would only ever be *one* DUID type for all 
> > time. But, RFC8415 clearly shows that multiple DUID types are 
> > defined and that new ones can be added through future standards action.
> 
> Ah, you are starting from a false premise there.
> 
> Just because something is opaque and never ever (in theory) used in 
> any way other than "X == Y" doesn't mean there's no reason to only ever have one method of creating it.
> As the idea of DUID is that it should be globally unique, ideally the 
> method used to create it should have the most sources of entropy 
> possible. But different devices have different constraints. That's why 
> we have LL and LLT since adding time of creation to the pot adds entropy, thus making LLT 'better' than LL, but some devices don't have a clock (and possibly, no persistent storage) making LLT unfeasible for them - i.e. LL is inferior to LLT, but real world constraints make it necessary.
> 
> So here the difference between LL and LLT is easy to see, as are the constraints that might force you to use the inferior one.
> 
> What people are asking you is : what makes this proposal so much 
> better than what's already allowed, given that's what's in there is 
> supposed to be opaque and so "it's an IPv6 address" has no bearing on 
> it's "goodness" as a unique identifier. And more specifically, why is it better than an RFC4122 UUID as defined in RFC6355 - 'better' meaning sufficiently better to justify adding to the global code base required to support it.
> 
> Both are 16 octets/128 bits long, both are intended to be globally 
> unique, both require persistent storage available to early boot loaders. So why is the proposed 128bit value better than the already defined 128bit value ?
> 
> Simon
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg