Re: [dhcwg] IESG Discuss on draft-ietf-dhc-mac-assign

"Bernie Volz (volz)" <volz@cisco.com> Tue, 01 September 2020 14:04 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 4F7F13A08CF; Tue, 1 Sep 2020 07:04:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=k9fHFB73; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SNOUBe37
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 uitqkDCTnCoL; Tue, 1 Sep 2020 07:04:46 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4F13A08CB; Tue, 1 Sep 2020 07:04:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20931; q=dns/txt; s=iport; t=1598969086; x=1600178686; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=A/gBEIlIJxHHw0aauxfgL3SYI9e7xBrfPHxIZYnIPFA=; b=k9fHFB73fZbmrgNjRWjAR9AxGdsFOQRuPIESnq6MGmZo58JjNU3WvYmd eMArTiPW1H+YBYemMRoGlGuy/wbtL4E0O0NvCsIXvKbFoIq+cLUP0YP3O pHTeb3XLEtU9wSBfa9sFJfZcGSUPxPFGuta8CZ+bCDs9zchzY2oRidnsL 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AHYHXPxxjdqWWSKjXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWDt/5sl1TOG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iKwMFNeH4D1YFiB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAABeE05f/4MNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTgFAQELAYEiLyMGKAdwWC8XFQqHdAONdZhxgS6BJQNVCwE?= =?us-ascii?q?BAQwBAS0CBAEBhEwCgiMCJDYHDgIDAQELAQEFAQEBAgEGBG2FLwglDIVyAQE?= =?us-ascii?q?BAQMSGxMBATcBDwIBCBEEAQEhDjIdCAEBBA4FCBqDBYF+TQMuAaRmAoE5iGF?= =?us-ascii?q?0gTSDAQEBBYVLGIIQCYE4AYJwgldLhxIbggCBEAFDgk0+hCUaJIMkgi2PWhc?= =?us-ascii?q?JDYl+gyKIS490gQgKgmWHaIdQixuDCYlvh2WLea4AhCgCBAIEBQIOAQEFgVs?= =?us-ascii?q?GLYFXcBU7gmlQFwINgTSMa4ElAQKCSYpWdDcCBgoBAQMJfI5tATFfAQE?=
X-IronPort-AV: E=Sophos;i="5.76,379,1592870400"; d="scan'208,217";a="535321370"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Sep 2020 14:04:45 +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 081E4iif003027 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2020 14:04:45 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Sep 2020 09:04:44 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Sep 2020 09:04:44 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 1 Sep 2020 09:04:44 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FEj3WJoP4kg18aKBA5zmYNIsh93Hvba18x5O3QQj6ttEqhguG2zjYUJzvzhQ1UnMwBSOA4O9BlNi7JIobUqYV6iIzG9gUREOgCu/GnNqHtiYEF+t/XFmFuFtWlLDGAWin00BfwKo2cjszWpAIr2E9IunrLP2LkwWz93euRLF+WOciFCUgZa5b7ayK078Gm+ZBhmYqKVwrudferCrYMthqfqVEu+MSMn3l4g2Y3LlsakQ0MnXBTPjyG5Jvso2robpVu1NfxESysO6MHQ5uNkaQyfeVfFCzXPedN4YA1VOrA5wJGU+Cdjc434n1UnXhrwWBvalHl9fflzrNp2AZupB1A==
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=YSEvtBqAR0waJ17JclyV/l5fHYWu984uzrnOCSlV7G0=; b=SqboRm9MzLUr2SC8nz/CDCX6YQF6tK1ScKasi3//sLu395e+j75BJvK2Tf4V0btgQHcaeOWJh+NYStSWAWfAmxwF7I1iYD/BMlzLhnHfuN+YLcdjJGgLbQYaRU9d+tGdLv9IWeMJezyWsUJzgBssLb+f0cxfKc8vEMPnMpC+rlFP8uil7aYasIhCObuhx2VFY8vvZddLufk5COcjTI90yiluFYNvfYXkl4KvbRCHV3wMFa4fTQVveQlctTf3pUeJQYtgyq7p/c9uvF8B+pw0p/CO/8FTRhh1W75DWPlThAeMgKS6xHoLg9eDe3AKOxeH/f4E2TyZiwCQahBUNmuvKg==
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=YSEvtBqAR0waJ17JclyV/l5fHYWu984uzrnOCSlV7G0=; b=SNOUBe372ndBZq/Rdi9PchtyuzxsIudXNZ3dlRXEIpE5WpwrKiBD3e1Ejxaer8MogfNxcpdV6m39je/jKCu3yLc4f5RbqhI50YiEue1hyx1an8t4IC4eywKXGDWHVWMmI3Q1G05lJ2PvAq0DAStb6CZsZ60ujLnuqqkTxZshKZk=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.23; Tue, 1 Sep 2020 14:04:38 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::4ced:474b:c85e:9533]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::4ced:474b:c85e:9533%7]) with mapi id 15.20.3326.025; Tue, 1 Sep 2020 14:04:38 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
CC: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, The IESG <iesg@ietf.org>, "'dhcwg@ietf.org'" <dhcwg@ietf.org>
Thread-Topic: IESG Discuss on draft-ietf-dhc-mac-assign
Thread-Index: AdZxfU4stYZWbK6XSxS6GPykxZ2LogO62AOQ
Date: Tue, 1 Sep 2020 14:04:37 +0000
Message-ID: <BN7PR11MB2547E1269EA5568E4443A515CF2E0@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <BYAPR11MB254931A67153209F909A084DCF430@BYAPR11MB2549.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB254931A67153209F909A084DCF430@BYAPR11MB2549.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.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: 0499e9af-8a28-4c2d-56cf-08d84e7ff6e6
x-ms-traffictypediagnostic: BN7PR11MB2547:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN7PR11MB254786FCE04E2CCE6E5983A0CF2E0@BN7PR11MB2547.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: HesAXf48OZSvJhcomIwVevofnOlW0kl9imxAVNDfnw5EM4VuOO80f6/Xwd6rJBCkG6uQRVhRHNc09YS9TL9yglgh/eklHaFmAXwTO7ce93pff/bCnGPys8GcV+gcN2S5UcjV44/tgTWUpsg2hF8raChz4UJ2fO3dWrOI2RnowkZgwogfZUNMOS53mCLtruoR/WbQv+7LaTYURre3IaHKyKPdV5iTGstNRh1jt5NVrFPgEgWbuYnmuSEea3DArGwVDjMLX1esxpr7VvQr5xPLKEhW+Cguw+Ff9HG4eZwPbSnQ7eq8ohQdn30hTrUE0MEb
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)(346002)(366004)(39860400002)(376002)(136003)(8936002)(86362001)(33656002)(7696005)(2906002)(316002)(52536014)(450100002)(186003)(6636002)(26005)(6506007)(53546011)(66556008)(64756008)(5660300002)(83380400001)(55016002)(6862004)(76116006)(54906003)(8676002)(71200400001)(66446008)(4326008)(478600001)(66476007)(9686003)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: F1y5nwT4h3+fS6L/MKeyJtVnM9QjZRfCXPxWYSrpUB98h/0uAybDc42S6I9JBCvdlmSpi7HX0ODZmKr1tYcaGKpSjuuATUYCkilk0RR9GaHtZ+jFVRlecEHk1+o66hblxy0nJGTyi5nJjuxLGN/szE3fTM5TB5Bmfwme7FYE/Ssz4GBOVtJOCqVxdjHUX0K1vqoGpqoVTD5nKn9ySBwOGW7L9sYtZTPv0rpofJJ+eAhxb2qgqGSSd682/NmMpxx7k6uCHJzS7qtycsGMe1VJVKXwi5XsCRlmQzQeb/w1TfbKu2V4FSPT7AMed2RcatxWZfnYQOpT5QBdI6UdY+fuktAoZCAfAB8NkKxrK5SURU3HWxyeRbyDDzcd+g0MpVlHuLdpp6XAVKrwfYJJFhUabVfsNLHtz7hVYprzu2XGjp/pKgwz60JI8qMTF7n6o4lDA9S/Kk8+rEMhJX9sq0bTquRqCnPOXsHJrNOZ8djPItxpKHmVRi/+5/nSuw/Gwb2yoeDJ9rRZEKHsmdUFi3BBfeCLwoLzKpyzIFY3B1h+ah/BNxt03PFvDNvq6boUy79jFeEgiwgQzfmvugUilNbKvCy5pjk1kmYtSF7hzz2K+Eq37jqXTQF0jz3PUS/Ok3V37soKCrRt5vhQsLMql46Lxw==
Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2547E1269EA5568E4443A515CF2E0BN7PR11MB2547namp_"
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: 0499e9af-8a28-4c2d-56cf-08d84e7ff6e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2020 14:04:38.1839 (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: Eo514dYw8JQg9GwvGiTWmKLZG4vt44cOXrUKc16+FporHPbTxnmu7IUUbTK4D6XV
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2547
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/dhcwg/vK48pEuSmlsyg9Rt7iUpHn0NQew>
Subject: Re: [dhcwg] IESG Discuss on draft-ietf-dhc-mac-assign
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: Tue, 01 Sep 2020 14:04:48 -0000

Hi ... just following up to see if this addressed your Discuss issues or whether more is needed.

Please let me know.

Thanks in advance.


  *   Bernie

From: Bernie Volz (volz)
Sent: Thursday, August 13, 2020 11:00 AM
To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; dhcwg@ietf.org
Subject: IESG Discuss on draft-ietf-dhc-mac-assign

Hello:

Regarding your discuss issues ... I offer the following comments (inline with BV>):

Client SHOULD, server MUST ignore.  In a couple of places in the document (sections 6, 10.1, 10.2), it states that the client SHOULD set 0.  To allow the protocol to evolve in future, I believe that it would be better if the SHOULD is changed to a MUST.

BV> I believe I have correct these items in the latest version of the draft (08).

There doesn't appear to be any specification of how an OPTION_IA_LL should be handled if there are no IA_LL-options, or it contains an IA_LL-option that is not understood by the server.  The text does also not specify if IA_LL-options can contain multiple options, and if so how those are encoded (presumably as an array/list of option values), perhaps this is already covered by the DHCPv6 spec?  Similar comments also apply to the LLaddr-options field.

BV> RFC8415, I believe, also doesn't mention how IA_NA-options is to be handled if there are none. Technically there is no requirement to provide an LLADDR option (an empty IA_LL-option field is usually interpreted as a request for assignment of an (link-layer) address). For example, for RFC8415, an empty IA_NA-options or IA_PD-options means to assign addresses (usually 1 but it depends on the server's configuration - as there could be multiple prefixes active on the link to which the client is connected) or delegated prefixes (again, usually 1 but it depends on the server's configuration). If you feel it would add clarity, I can add text to clarify this. Perhaps adding the following paragraph in section 10.1:


   The IA_LL-options field typically contains one or more LLADDR

   options (see Section 10.2). If a client does not include a

   LLADDR option in a Solicit or Request message, the server MUST

   treat this as a request for a single address and that the

   client has no hint as to the address it would like.

9. Releasing Addresses

Once a block of addresses have been released, can they immediately be allocated to a different client?  Or should they avoid being reused straight away if possible?  Perhaps this consideration is already covered by DHCPv6, but it probably makes sense to say something about this, either in section 9, and/or maybe in the security considerations.

BV> This section refers the reader to Section 18.2.7 of [RFC8415]. That text states " The client MUST stop using all of the leases being released before the client begins the Release message exchange process". But this does create an interesting issue in case of the link-layer address as it is not clear how the client can transmit the message if the link-local address it is using is based on the to be released link-layer address. For the hypervisor case, this is not an issue because it is presumed that the hypervisor itself has its own link-layer address. It is an issue for a client. Perhaps we need to clarify this a bit with something like the following.

Note: If the client is releasing the link-layer address it is
using, it MUST stop using this address before sending the
Release message (as per [RFC8415]). In order to send the
Release message, the client MUST use another address (such as
what it used to initiate DHCPv6 to obtain the address).

BV> Regarding your point about reuse, I think this answers that - as the client MUST have stopped using the address, it is perfectly OK for the server to immediately reuse that address. I will however note that at least for DHCPv4 and DHCPv6 (v6 address/prefix delegation), server's often support a configuration parameter to delay reuse of an address (either if release or it has expired - for the expired case, this is more usual as clocks may not be synchronized).


  *   Bernie