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

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

Return-Path: <volz@cisco.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 6FC753A1158; Fri, 15 Jan 2021 12:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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_DNSWL_BLOCKED=0.001, 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=Jy7WIhu2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NEm542FA
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 mveLwaVIk6AW; Fri, 15 Jan 2021 12:21:46 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C283A1154; Fri, 15 Jan 2021 12:21:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29308; q=dns/txt; s=iport; t=1610742105; x=1611951705; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2l1vZrg3+WhwYKAjUbqzWpoeO6qyFdJfXccSAmIchoo=; b=Jy7WIhu2qh7n5NyiZn1AIn0r2HIR3i6clEXjjM5jpz4U0zV1GEzW8KE6 kxovCWptCSL0rxBPJoRoqyY8gzNWPlek0bWaSqR/T2c5mP42sKDMEeaKr OtXbhsgENjgVvyjQnReKI02b3EYOxT75hBtwwczLF9gRUtNnTVIWhE0o3 w=;
IronPort-PHdr: 9a23:NNnD+R3q1Rqbh59zsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxWGu6dni1LIW4qd4PVB2KLasKHlDGoH55vJ8HUPa4dFWBJNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkJSFcf4aBvZpXjhpTIXEw/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOAgDK+AFg/4MNJK1YAQkaAQEBAQEBAQEBAQMBAQEBEgEBAQECAgEBAQFAgU8CgVFRB3ZbLy8KhDWDSAOOAgOKHIR0igOCUwNPBQsBAQENAQEYCwoCBAEBhEoCF4FWAiU4EwIDAQELAQEFAQEBAgEGBHGFNAEFAiUMQwEBBAsBhR4BAQEEAQEYCREMAQEsCwELBAIBCBEEAQEBAgIjAwICAh8GCxQBCAgCBAENBQgBC4MTglUDLgEOpEICiiV2gTKDBQEBBoEzAQMCDkGDAQ0LghEJgQ4qAYJ0hAGBCoFCg3ImG4IAgRABQ4JWPoIbNwsBAQEBAQEVgRkBDgYaBRAPFIJeNIIsgU8JAWIHBg4uJAQvIgEBFAwwCwsLChUHKxUEASMBAQqQLAeDJaQXOVgKgneJLo0bhUCDKoEwiH+FYI8vlBmLGoJ6gyWLFUeENQICAgIEBQIOAQEGgW0jgVdwFRohgmkJRxcCDYE2AYxqCQMXg06FFIVEdAI1AgYBCQEBAwl8hVCBEIQvAYEQAQE
X-IronPort-AV: E=Sophos;i="5.79,350,1602547200"; d="scan'208";a="854479300"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jan 2021 20:21:44 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 10FKLi5q023657 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Jan 2021 20:21:44 GMT
Received: from xfe-aln-005.cisco.com (173.37.135.125) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 15 Jan 2021 14:21:44 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xfe-aln-005.cisco.com (173.37.135.125) 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 14:21:44 -0600
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 15 Jan 2021 14:21:43 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FsyQaXiPjYhVdgYc3f7aISveDBP2LCGqpC3dgm50Sk5XKRRafY+K4W3GVDrHHt+V8/Q7aD0PsZs2h/TgqC2ONBhZYQuCsK8NyMcRGN34EsAb2zn4IDeiklH8YOD7NbAsicDtVjac6S+0vSxp2lDtBkbhywEkyL/nEiXSigoM1xMOLXtU9jqZ+MOcrJeueXloumk22dJpEks4ZYjY6PqKv5zZ6Jz3mwVxYhXWRjlMiopNm3c+fPPaclLJr190XRUirlPX+zcFQ5qhgkrry/eCtO2SZqFs5u91Lfwwylqz+tyqRGtT6ZDcd3ocEc21YCuJ7fTey8X/uAdspgvnxzONtg==
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=2l1vZrg3+WhwYKAjUbqzWpoeO6qyFdJfXccSAmIchoo=; b=jn0A42sPN4C6QcQGrJZ1XXAw1TahhleNFmN9WtgsL0rgdkMIuyd2Y0FvXlpk6dQgKNuftgSKip/MHlcgcDXKyBRdZ1TMfhFMeF5caYCeU9mhYqa6e5YeJNNvudGWAJtdPFQL/sh53kallPg2JTJ/CZm5r49MQfKqhgz1BtWLRQQJA6MpP/J2p/CpcREgA5FM0VYVzpsoJKAqvRNMlBCCKa0HpujAtoFEcIVsh1agV717vMCc9OARIQg63M8k0x/srgvOb7XyTJJeiTzQOXWLb6eQawh39hdYetOp+guMkD1MKgr6MhirIgfqlt9T6aDAvOlJI9w5lYBuIaNr6VM1fg==
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=2l1vZrg3+WhwYKAjUbqzWpoeO6qyFdJfXccSAmIchoo=; b=NEm542FAToKkPRQ+fZY5oAloxiutVNZarjxxS4rnIzNL7XsNnuhMj9MVJqVsuJDD997oj5Q40vrvoVmZdp/UlmKP62apkixAyV6vP1KryRWXXZR4Gw8HDGaGgeQQkP+GPXEHZEUPiwdevTOkOxqxqGTsM7AAud262gBqvi0fmcA=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN8PR11MB3585.namprd11.prod.outlook.com (2603:10b6:408:89::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.11; Fri, 15 Jan 2021 20:21:42 +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 20:21:42 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Bob Hinden <bob.hinden@gmail.com>
CC: dhcwg <dhcwg@ietf.org>, IPv6 List <ipv6@ietf.org>, "Dickson (US), Sean M" <sean.m.dickson@boeing.com>
Subject: RE: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
Thread-Topic: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
Thread-Index: AQHW63BA/gWFg6pFskKiLLH4P7jyCKopH+Sg
Date: Fri, 15 Jan 2021 20:21:42 +0000
Message-ID: <BN7PR11MB254786BF567BFBC104199BB1CFA70@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <f6ae99d24c9447399bd3b2e3b3c029c4@boeing.com> <74460CA0-A839-4179-A162-6946456591C7@employees.org> <c938d77ed2b347da8dc23e1a8190b709@boeing.com> <1BDA0163-158C-4C0C-9D63-BC62D170308E@gmail.com> <1d654c0732a244e394178a38a4aa019d@boeing.com> <ed7ce7a5020348cd98222bf9bdd66eed@boeing.com> <C9AE494A-0372-4294-AC1F-E25FEAEBA4DB@gmail.com> <cb1cb55e5b634ceea3dde33b8c8816c1@boeing.com> <db9339dbe4be499bba9d098732ace1a3@boeing.com>
In-Reply-To: <db9339dbe4be499bba9d098732ace1a3@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: [24.233.121.124]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 814a6c26-c8fa-4939-c493-08d8b9932c1c
x-ms-traffictypediagnostic: BN8PR11MB3585:
x-microsoft-antispam-prvs: <BN8PR11MB3585D17E70FBE595A12C1CCACFA70@BN8PR11MB3585.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: Y+nF5c2C+wDzUVEzgdbhGbnKWCC2IAmxOBwe3JbhMDA1IJ6WtsTckND3bUXOosaFpF6bwokkE+rHU76xEIQ7+K2aJNSrfdaOQxJAYxf9U6rjHxCZcGfR53U8ctGEsVAaEGcD5DaX/aspKL8HrCzck7Wh/76fWzsN26pKz+EYkH2H/VxZJzJ3H9oBiOPonOrBW+UaoWLukokp6JBvBPZ/6v7SdcB2bN8OoU8aFNs+IavNhKFVMVbgWT+xeujbJBQtqcVkapXveRV+A5xZ/LJWMpPPBY1N18OQk98ZT0MdKfGrPOj4wJm98YTF3cnPlRu0CA7edYTI0ttAyoOoFA3yrCQVCscHagQKtRPsvJrKDX61V9If0Gq1szjIp93sWigd/YruLvc5IPJ2rjJYZfiCoclHwJMndWj1Tz/7jCBEs7b0ozqMJm9xFxzFktsoEczmXWg8/mhDuqoYjVW7I4IbMrRbv4Jnl+u/+Gi5SsOe8Ikg9FO14/SmrIdozx9K8x5RT5zYwPHIx+bEWyJwt2tzEkUQMR14Orhtkz/XQAZ0P/e9NIZwVTOMDu95ncecCEuPBDrvllI7NEkGaKmElkBItw==
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)(39860400002)(376002)(346002)(366004)(186003)(6506007)(33656002)(4326008)(83380400001)(66574015)(52536014)(478600001)(55016002)(26005)(76116006)(66946007)(66556008)(66476007)(110136005)(966005)(2906002)(86362001)(30864003)(71200400001)(7696005)(316002)(5660300002)(8676002)(8936002)(64756008)(66446008)(53546011)(54906003)(9686003)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 3D5XvZy+mVgOFAGUdj6iNFkX5Sc5CxBudRxmRUXkV25Fr+Qbf3U0/1WbjeXNFiBgJP9le8D/1K1xRdfRIlYj9N/1s+pUZGoSnl7BWl+pKgWFxPAEOcidbl8M+raCIdo1kwo4k5E8/Anpd3Cd/8/yrny/PFTbBQEDL1u/Mk2/5ltsWIkI4miki2aSDU88RErwxrH16td8tu9zch++0iBRYUJ3nUbi7EZWotw6nJ8L1jX+2bqkDonXj4/DxvyTkTb38Qx/AI2o5EWbagLUrIvDXEiij1VBI85NfhKX3U8ZCfkqeKbedemnLm9sauNnuduJc46O/Z3X6PbA520KjWukDbpaP43sxpCxT2/uBYBj1nFOtMgt4CiAbYgI6Pcw1p+AM26UWAvyN45gux23RHtbscqBnnlp5KXNznP51cz8GUHO3zBMqG65mTqE3uRyg1pG2G6YybAgT7Le/+1dHsTGkqNYP/q+AlS9a+I/+RDAFRL3j8ZKScFkAKg1xuHH3QIt1a257bdGyPWNN0Jvn+hPgF/PRMEF+3BXhO7fDP0WPF8yuzxD1cliI43DqaR55HD/7G8MzP0EwOVqAP7xP8Pbr+swjkWilyK3HWGL/BmXRKTFj2nES2mV3OuO1S2dg9jwPBqKztiPz4DUhxxF/D3PwwGngV3Ub8akTkAltzrLcfiQWHHd/7V9rR8uRTtqKzr8lb/V/0auPD1VBRu5TMriY7xO/jcJwyZXAUp8ydmEatlohJfsD2rIu+GouGaR6yBf4K7LCsS7D2wDOdVo5u6ixAdu7gkoJeHF1GjLfsFxuAnOhuLbbXPlHVgs56bZSOfp78WXk75L302rQql6bsoLw2tx8Y1p6exOnaGiecI4oSTqCPbjsCbLEmYZXLrY0uCUWFeY6vXToNtjmGiv7smdrW9AJYmgoU0zKM2qf01VDyvUybF/xojWOYsEz8B+MnEqqoSXjA5OFUvgI0GL3DbGoJ5n7Lpf8BKPCyY1pKFA4+0=
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: 814a6c26-c8fa-4939-c493-08d8b9932c1c
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2021 20:21:42.2849 (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: 40KPY0/KHNtx7urMD5b5mvDO66xgTXEZFz/rlgmBZZv4+NrXHETmuhrXm9Z+17zT
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3585
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/szkWwDiX3I7xqUnfygigVFh02WM>
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: Fri, 15 Jan 2021 20:21:49 -0000

If you're specifying requirements for a closed network in which you are not mixing other devices (i.e. ones that might use real UUIDs), I am not sure I/we can say much.

But if this is an open network where a mix of clients operate (or might in the future), I would be against doing this. Again, use DUID-EN in that case (the 4-6 extra bytes should not be an issue - you don't necessarily need the 2-byte type or you could even use a 1-byte type or no type; you can always get a new enterprise-id if you need a different format in the future).

- Bernie

-----Original Message-----
From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Templin (US), Fred L
Sent: Friday, January 15, 2021 1:57 PM
To: Bob Hinden <bob.hinden@gmail.com>
Cc: dhcwg <dhcwg@ietf.org>; IPv6 List <ipv6@ietf.org>; Dickson (US), Sean M <sean.m.dickson@boeing.com>
Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt

To everyone who has commented, this is the particular exchange for which I have been expecting but have not received follow-up discussion on the answer I provided. I will not answer any more questions, because I would simply be reiterating the same answer I provided in this exchange below.

If I get no follow-discussion (especially from Bob Hinden) I will consider the DUID-V6ADDR idea "dead" and revert to using DUID-UUID to encode 128-bit values of all types *even if they are not UUIDs*. Would everyone be cool with that?

Fred

> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin (US), 
> Fred L
> Sent: Thursday, January 14, 2021 11:46 AM
> To: Bob Hinden <bob.hinden@gmail.com>
> Cc: dhcwg <dhcwg@ietf.org>; IPv6 List <ipv6@ietf.org>; Dickson (US), 
> Sean M <sean.m.dickson@boeing.com>
> Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: 
> draft-templin-duid-ipv6-01.txt
> 
> Bob,
> 
> > -----Original Message-----
> > From: Bob Hinden [mailto:bob.hinden@gmail.com]
> > Sent: Thursday, January 14, 2021 10:44 AM
> > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > Cc: Bob Hinden <bob.hinden@gmail.com>; dhcwg <dhcwg@ietf.org>; IPv6 
> > List <ipv6@ietf.org>; Dickson (US), Sean M 
> > <sean.m.dickson@boeing.com>
> > Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: 
> > draft-templin-duid-ipv6-01.txt
> >
> > Fred,
> >
> > > On Jan 14, 2021, at 8:53 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> > >
> > > Bob, I think the answer to your question is quite simple. RFC8415, 
> > > Section 11 provides the motivation for having more than one type 
> > > of DUID, and RFC6355 is an example of how new DUID types are added through standards action.
> > > The precedent for adding new DUID types according to published 
> > > procedures is therefore established.
> >
> > That wasn’t the question.   I didn’t ask if other types of DUID were allowed,
> 
> A different poster (Ole) made an assertion that seemed to call into 
> question why more than one DUID type is necessary - the above text was 
> included to to justify why multiple DUIDs are provided by RFC8415, and 
> why additional DUIDs can be added through future standards actions.
> 
> > I asked:
> >
> >  "It's unclear to me what the purpose of putting an IPv6 address in the DUID is. Would you mind clarifying that?”
> >
> > Several other people asked similar questions.
> >
> > > In the specific instance of the proposal for establishing a new 
> > > DUID type to carry an IPv6 address, the intended use case is for 
> > > IPv6 address generation methods that produce an address that is 
> > > designed to be a unique and stable identifier for the node, which 
> > > meets the requirements of what can be used as a DUID per RFC8415, 
> > > Section 11. This is certainly the case for (H)HIT per RFC7401 and 
> > > draft-ietf-drip-rid, and I suppose the same case could be made for 
> > > other cryptographically generated IPv6 addresses such as RFC3972. 
> > > Future IPv6 address generation methods (whether or not 
> > > cryptographic) could also be designed to produce a unique and stable identifier for the node, and would be covered under the proposed new DUID type as well.
> >
> > Again, why do you need to use an IPv6 address for this?    Why can’t one of the current DUID approaches be used?
> 
> [RFC7401] and [draft-ietf-drip-rid] are examples of IPv6 address 
> generation methods that generate an address intended to be used as an 
> *identity* but possible not as a *locator*. In other words, the 
> address could appear in control message ID fields but may or may not 
> be "ping'able" in the data plane. And, even if it were "ping'able", 
> pervasive use of the address for data communications could present an unacceptable privacy exposure.
> 
> > I note that DHCPv6 is usually used to get an IPv6 address, so using an IPv6 to get an IPv6 address seems very odd.
> 
> Continuing from what I said above, yes this would entail using one 
> type of IPv6 address (a pure identifier) to obtain one or more IPv6 
> addresses or prefixes that can be used as the source/destination addresses for IPv6 data plane packets.
> 
> Fred
> 
> > Bob
> >
> >
> > >
> > > Before we go down the rathole of "IPv6 addresses must be assigned 
> > > to an interface and not a node", please refer to the earlier 
> > > messages on this thread where the suggestion was made that the 
> > > stable and unique address could be assigned to a virtual interface 
> > > (e.g., a loopback) and not an interface that may be subject to 
> > > change such as due to a hot-swap of an interface card. Finally,
> > > RFC4291 says the following:
> > >
> > >   "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."
> > >
> > > From this text, we see that an IPv6 address may be used as an 
> > > identifier for the node, which is exactly what a DUID is. And, an 
> > > IPv6 address is unlike any of the existing DUID types, since by 
> > > definition the address must be in the format specified by RFC4291. Hence, a new DUID type is requested.
> > >
> > > Fred
> > >
> > >> -----Original Message-----
> > >> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin 
> > >> (US), Fred L
> > >> Sent: Thursday, January 14, 2021 8:19 AM
> > >> To: Bob Hinden <bob.hinden@gmail.com>
> > >> Cc: dhcwg <dhcwg@ietf.org>; IPv6 List <ipv6@ietf.org>; Dickson 
> > >> (US), Sean M <sean.m.dickson@boeing.com>
> > >> Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: 
> > >> draft-templin-duid-ipv6-01.txt
> > >>
> > >> Bob, I have been offline until just now due to windstorms that 
> > >> knocked out power and Internet access in the Seattle area over 
> > >> the past couple of days. I will reply to your question shortly.
> > >>
> > >> Fred
> > >>
> > >>> -----Original Message-----
> > >>> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> > >>> Sent: Tuesday, January 12, 2021 4:43 PM
> > >>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > >>> Cc: Bob Hinden <bob.hinden@gmail.com>; Ole Trøan 
> > >>> <otroan@employees.org>; 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,
> > >>>
> > >>>> On Jan 12, 2021, at 3:05 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> > >>>>
> > >>>> 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.
> > >>>
> > >>> How about telling us now.
> > >>>
> > >>> Bob
> > >>>
> > >>>
> > >>>>
> > >>>>> 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/yOfWHSnt36Hvjr44OE
> > >>>>>> RjK0OFvhw/ 
> > >>>>>> https://mailarchive.ietf.org/arch/msg/dhcwg/YZq_aPf1C82ZFT_bT
> > >>>>>> dXOXVXTPW0/
> > >>>>>>
> > >>>>>> 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
> > >>>>>> -------------------------------------------------------------
> > >>>>>> -------
> > >>>>
> > >>
> > >> _______________________________________________
> > >> dhcwg mailing list
> > >> dhcwg@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg