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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 02 September 2020 14:00 UTC

Return-Path: <rwilton@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 95A473A0C60; Wed, 2 Sep 2020 07:00:47 -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=WDREZvMd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eWA5Y+ZM
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 m6v2nLEavV7p; Wed, 2 Sep 2020 07:00:45 -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 40A7E3A0C50; Wed, 2 Sep 2020 07:00:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30267; q=dns/txt; s=iport; t=1599055245; x=1600264845; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IqS49fl7M4KstsQaZ1piVfLscOf4zSjvFEoxICNisx8=; b=WDREZvMdBvYqHqQMXwWdVUPgtL8CLWgsTPHljPK/JfB902D4/yTLApDp ia/OItpQvMFYKRBMEoB6ps81bi/RjEALZPGHJKiGRv+IIrVZ9VFA2STmG 96MBhkibPgjPnXFIs80gMxYd/pNqsGzdllAwT06O5MFF+9eTrcSQsJpYB o=;
IronPort-PHdr: =?us-ascii?q?9a23=3AmZ20WR10SxVlHJI5smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGuadmjUTCWsPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoOklOE8G4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AACTpE9f/5hdJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTcGAQELAYEiLyMGKAdwWC8XFQqHdAONeZhxgS4UgREDVQs?= =?us-ascii?q?BAQEMAQEtAgQBAYRLAoIjAiQ1CA4CAwEBCwEBBQEBAQIBBgRthS8IJQyFcgE?= =?us-ascii?q?BAQEDEhsTAQE3AQ8CAQgRBAEBIQEGBzIUCQgBAQQOBQgagwWBfk0DLgEDpTE?= =?us-ascii?q?CgTmIYXSBNIMBAQEFhUAYghAJgTgBgnCCWkuHEhuBQT+BEAFDgk0+hAgBEgE?= =?us-ascii?q?JGiQQgxSCLY9aFwkNiX6DIohLj3SBCAqCZYdoh1CLG4MJiW+HZYt5rgCEKAI?= =?us-ascii?q?EAgQFAg4BAQWBVgI2Z3BwFTuCaVAXAg2BNIxrgSUBAoJJilZ0NwIGCgEBAwl?= =?us-ascii?q?8jjwBMV8BAQ?=
X-IronPort-AV: E=Sophos;i="5.76,383,1592870400"; d="scan'208,217";a="535851804"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Sep 2020 14:00:43 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 082E0X0k000890 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Sep 2020 14:00:43 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Sep 2020 09:00:40 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Sep 2020 09:00:39 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 2 Sep 2020 09:00:39 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q1knECx4oKW0veVi4QWA4xQ9F9MQIT8Yv+3wMXDjesfjlCPyziS/yA72uaxnibgcZIdqLyiT1gv3Fj5TFz/LFXL9f7fKaEQv0exALyjfUDkx6u35uhUT8OXIYps6pzsO2ZVmNYZ8U8AsficL57M2X9LafCJ4ciTHEJ5TmJykVBrnPpj3zzJqnAGs0jp81CQ2H8o6EIag0q1Z+/2OpduIqMFGtj6DQd/RtpNb7sIFoAPa9HFveq3yoHxCkGybIXx6ojlF33GJYzB1Hzd1/W/P+t9P/LMbdjUeTdn3BMzILqB5cIfNntS8+fK2PeUGWetVOhLSmhMaR9Sc7fSiKVSo+Q==
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=WH+ElT0To0+bLH4fsa/PX80LjkDUhE0xYfmOtXEbXxA=; b=LQWG1081vm+rW+NSLEDK02SB4+UmTTyhtXnZaOv8kRj4mSVY7DaunVDtKnXZa+cs04FY+NDJLOXgJa3pgJhISvHSvYbRaF4r8JXmpP/nquLHpgae9yso4gfMHATctfGC/63aV1z38Qj1gaV/YCHwDXkewE8rNV4H+aAOS7NsKg/DoNEWXFnjkYY7RBeHq7jOJZl4/yWgUvzWHtWoomVdU0o80H2jyg9jpa4HHHHrMC0mIAQH3qfKrMF5pPi41rJDHljvmbVjVJ7HA36t8rQ6c4bTjgxypf5Zz2HUS6+33EDPuHXNw50jEC1c/NzNw0AT32SgZkCSRjRAQvEIUIL0jQ==
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=WH+ElT0To0+bLH4fsa/PX80LjkDUhE0xYfmOtXEbXxA=; b=eWA5Y+ZMzucKJ9TfIAFJx/lLZg2DRoTR3fCUei5J2yhaN+ERYOTs3ScrcSLqISdKNHl50vOYwiHWZHgzpz8Xdt6s/UEUvfoQKnDqrontU7CEE+5YGA2Kg+9Zhy7rSVCt3rwoh7UkyMNex91d9p5HKdn906YolKtrZsrE8pRddg8=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3203.namprd11.prod.outlook.com (2603:10b6:208:63::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.25; Wed, 2 Sep 2020 14:00:38 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1%3]) with mapi id 15.20.3305.026; Wed, 2 Sep 2020 14:00:38 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "Bernie Volz (volz)" <volz@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: AdZxfU4stYZWbK6XSxS6GPykxZ2LogO62AOQADGeMLA=
Date: Wed, 2 Sep 2020 14:00:37 +0000
Message-ID: <MN2PR11MB4366C478464D73F97DCC0798B52F0@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <BYAPR11MB254931A67153209F909A084DCF430@BYAPR11MB2549.namprd11.prod.outlook.com> <BN7PR11MB2547E1269EA5568E4443A515CF2E0@BN7PR11MB2547.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB2547E1269EA5568E4443A515CF2E0@BN7PR11MB2547.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: [82.15.79.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2d323022-5d85-475b-2d82-08d84f48922f
x-ms-traffictypediagnostic: BL0PR11MB3203:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BL0PR11MB3203D022300409D3B385AADEB52F0@BL0PR11MB3203.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: s5lypLPnDstxtmq/OhfAqtQVz0Qsn43IM998BCjsE7h23XIw8rpgDWRs7xTDUQT4/EKe78C8P3KnRHOpUn/p0sf1YVIH/kuwQzkID4CI1YVrIrSQ/IReyxKY7usVH+sTmUZQEKaKMSYpYEbAKXVL1A7fqsEH9L2Ain44wrxC0tye19ApSKWonGJN2JQlhOhQfEGBg7lOdNcaq2Uqu25tcdRHrh1MfcXQYWOcBTQCASG6ucyQgyHVYzDHUHRaVqqzJ6CHP5FCPQNcBtk2jN6jKuqrIuKGXzyig/4SA/NnFkFWYNBHxJWth/UyxMdONQ1I
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(396003)(366004)(39860400002)(136003)(86362001)(66446008)(33656002)(66946007)(66476007)(76116006)(6862004)(71200400001)(83380400001)(4326008)(64756008)(66556008)(5660300002)(186003)(7696005)(6636002)(52536014)(8936002)(8676002)(53546011)(9326002)(316002)(54906003)(450100002)(26005)(6506007)(9686003)(55016002)(2906002)(478600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: CioqSeNooOq708q4ogPU8QB5zceax3LtkaBr/k1NSv+n99k3rCrabimYIWG+HfDOqfReO3rb2t3AIMwmI3se7PVC0osyswUfDOt2Onx7d1PHOb8OehuctGRYE0q0+j4ckCrYy7B6Mcbudgk6w6LRA71ZSYHl2Wx5jHIhEbWuM3/hsmIPrOLTKAEZSqRIL0DPc3SPSBLET0mbUmNL0POUXHpsyvxi973f2072C/GlbLmlx7DLOW2/k6AqKJWsvECdF7M0OpudQpCKHpTUGjjaLumpQCz8vn/pqycawlT6ycaMEvGHQR0tIkRp0KwbTNgXEQWC33KiKaoge7az/wg/qdizu3O1ZxfjXMDX9mWv6l3DJuV+EPT2sYev0hmiJ05JpIWN56zAPvOMaGrcryktPUZzfzBIjwO38Rc8WrVWq2Gp6T2LWIzf17AWySTeLfLUQXKptr80jhhakCCX3eOcQWgAsRbRMVEtEfJ36f7xbx/HEBx6XdXcMDTww+9Q2mE1Ws2ZNKxc5YX4hKylniP8A05C8PYUHOK2rI7dVph7ld/5FfEmdG7DCBn9q1FeBY1UMB16kaGIxP7Yt28DCkjsPZdvdeVTsNAFOx2YyyzGzeC3t9Sl3Ht3otVpqwOW70NcDkJOvRAMwr2Y/hdvRXAIhw==
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366C478464D73F97DCC0798B52F0MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d323022-5d85-475b-2d82-08d84f48922f
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2020 14:00:37.8701 (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: 6W1cAC6ONlpuMMMGaq8xVBaS3HRs9vXZbEYvMFjIh7yAJw/L9PXmZg+HBw2JzBiAeW7uDvPHEca03DKHGYRLQQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3203
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/CkQxFxV6vMuQO_F-r2AzLAC539w>
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: Wed, 02 Sep 2020 14:00:48 -0000

Hi Bernie,

Sorry, catching up with email after PTO ...

Yes, your proposed edits all look fine, except I have some proposed edits on the last paragraph that you are free to take or leave.
Old:
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).

New proposed:
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
the one originally used to initiate DHCPv6 to provide an
allocated link-layer address).

I will clear the discuss.

Regards,
Rob


From: Bernie Volz (volz) <volz@cisco.com>
Sent: 01 September 2020 15:05
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Eric Vyncke (evyncke) <evyncke@cisco.com>om>; The IESG <iesg@ietf.org>rg>; 'dhcwg@ietf.org' <dhcwg@ietf.org>
Subject: RE: IESG Discuss on draft-ietf-dhc-mac-assign

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<mailto:rwilton@cisco.com>>; dhcwg@ietf.org<mailto: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