Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

"Bernie Volz (volz)" <volz@cisco.com> Mon, 04 November 2019 15:17 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 6713D12089D for <dhcwg@ietfa.amsl.com>; Mon, 4 Nov 2019 07:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=QMelqsd0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JET1S8rw
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 Zw4D-eUTa4Ye for <dhcwg@ietfa.amsl.com>; Mon, 4 Nov 2019 07:17:26 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD4B120880 for <dhcwg@ietf.org>; Mon, 4 Nov 2019 07:17:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8984; q=dns/txt; s=iport; t=1572880646; x=1574090246; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uJXtJdJZJEQSgN0nOuordkKKX7bHniMh7yAnnK/VGqY=; b=QMelqsd0myZWDTT07Uc7Rap5+2829y03Lti9ALvQsiZqQBeATemzr+A5 QhnD3k9Rl7nI32GfdMI4mZeroyVJa3DQ/F6fNfZvJ8yBcz8PQ4Qxz4vhE GluW02ywpbXqGvxMahWLCPNr2Zb1wA0p++Y50bJf6IVYc9ZyAaE6ORLhP w=;
IronPort-PHdr: 9a23:ZKvQ7hExBDNudFEG3nj+951GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4w0Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0ETBoZkYMTlg0kDtSCDBjlK/r4Ryc7B89FElRi+iLzPA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ATAADTP8Bd/5hdJa1mGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFqBAEBAQELAYFKUAVsWCAECyoKhB+DRgOKd06CEJd9gS6BJANUCQEBAQwBARgLCgIBAYRAAheDdyQ1CA4CAwsBAQQBAQECAQUEbYU3DIVRAQEBAQIBAQEQEREMAQEsBAgEBwQCAQgRBAEBAwIfBwICAiULFQgIAgQBEggagwGCRgMOIAEOpmkCgTiIYHWBMoJ+AQEFgTgCg1IYghcDBoEOKAGMEhiBf4ERRoJMPoEEgV4BAQOBPgEBCBgVgnkygiyPfp0KbgqCJIcRjkCCPIdahDGGZ4Q3hD2KBYgukSkCBAIEBQIOAQEFgVQDNIFYcBU7gmxQERSDBjiDO4UUhT90gSiLBg8XBIEHAYENAQE
X-IronPort-AV: E=Sophos;i="5.68,267,1569283200"; d="scan'208";a="357129978"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Nov 2019 15:17:25 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xA4FHOeh005825 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Nov 2019 15:17:25 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Nov 2019 09:17:24 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Nov 2019 09:17:22 -0600
Received: from NAM05-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.1473.3 via Frontend Transport; Mon, 4 Nov 2019 09:17:22 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ezTeQlSOoJVYOxCFNQItV7Wd0vRvrREYfTxUXDFekUaCyffN4N+cmSq8B61lJ4JuHluyCWZPXibr0FbCDq0/9byRcsnr5RU2Uu5EBf9kRM76h8+MYtE+/j9laV532+Txa9covOfV4LGT1mhyCEPNwNS0BmC2nT8kQmMAaVSF7AwjIDK0beznPg1a03YM6AjyUGs+Yb5cD5w54KDb18jaVTo4nv5sp4U6W7L5t3YcXvjeNznetuYbZar/nw580y/jDqe+Lu+GoJ805nLxMqRThL83TeuiDo/Ja+zk07FD0nvi7ks9u2iY8AXYWZIXLEhennKgkFzMDly8qaG6ETSVtw==
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=uJXtJdJZJEQSgN0nOuordkKKX7bHniMh7yAnnK/VGqY=; b=Ef7TL1r5ADAC3Z3cYs0oCUcml/WxlTEPqu7Sy8H1vYdOGwsRQKFbVnEO/foy7SxiWOdCyamvyqm9CtP7gzJnSUPage8BlxWWcbsFNQZRep9ST7M09CMqQQa6+exNrX0HKDSkvLKJxfJ2Xkg2NPdJbhxQy1OTajhufzD5n6YFqnhSGQ0S+bgFuvGCCJ/pV89jrtU/Exh3ATGQfTOLRsez8YeSNueg3YoIwsPliEj06zdCJqVi4f9RiPMeFUpuiLnOqbFjmvEcAjOI4x2T1mIcty6CxK3puhu0FuNrjuTQYxSE9x8V4AYWGXxYHISullgQmFcrDE+CIe0TdujJKyLjdg==
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=uJXtJdJZJEQSgN0nOuordkKKX7bHniMh7yAnnK/VGqY=; b=JET1S8rwtvwnJJIhx3x/29xKSImA9e0wTknOU/UezWHQQa2dWeUtd/JfZ35yg3BSIMMHeFAa8mNaKp4HrOdxFU0S/PIWZBzzevtdAxEe5CRDZJe9xNL/WosJs69GM2tsN1+Hi0UaFR6ffRHbXY4Wm/p1HWzUDWA0v2mTuBz82+s=
Received: from MWHPR1101MB2288.namprd11.prod.outlook.com (10.174.97.139) by MWHPR1101MB2109.namprd11.prod.outlook.com (10.174.97.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Mon, 4 Nov 2019 15:17:20 +0000
Received: from MWHPR1101MB2288.namprd11.prod.outlook.com ([fe80::808:4d44:a5d1:c7f6]) by MWHPR1101MB2288.namprd11.prod.outlook.com ([fe80::808:4d44:a5d1:c7f6%11]) with mapi id 15.20.2408.024; Mon, 4 Nov 2019 15:17:20 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17
Thread-Index: AQHVkCewWbl519udNU66WIbAmH8PxKd7IK/Q
Date: Mon, 04 Nov 2019 15:17:20 +0000
Message-ID: <MWHPR1101MB2288427480F9B15A2E0E461FCF7F0@MWHPR1101MB2288.namprd11.prod.outlook.com>
References: <c9976d83-7243-cf44-a9c6-ff858afb5247@gmail.com> <87cdc523-58ca-1681-31ca-f1733f8aa3d2@gmail.com>
In-Reply-To: <87cdc523-58ca-1681-31ca-f1733f8aa3d2@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com;
x-originating-ip: [173.38.117.85]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cfd995cd-564f-4259-b151-08d7613a1630
x-ms-traffictypediagnostic: MWHPR1101MB2109:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MWHPR1101MB21093308B30EDD3E5BE84F4FCF7F0@MWHPR1101MB2109.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0211965D06
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(39860400002)(396003)(136003)(376002)(13464003)(199004)(189003)(25786009)(33656002)(9686003)(76116006)(8676002)(55016002)(66066001)(6506007)(53546011)(71200400001)(71190400001)(99286004)(2501003)(11346002)(6436002)(8936002)(66574012)(5660300002)(476003)(6246003)(6306002)(316002)(81156014)(229853002)(446003)(52536014)(81166006)(110136005)(14454004)(6116002)(186003)(86362001)(256004)(14444005)(486006)(478600001)(966005)(66446008)(64756008)(66556008)(66476007)(76176011)(66946007)(3846002)(2906002)(305945005)(102836004)(26005)(74316002)(7736002)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1101MB2109; H:MWHPR1101MB2288.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:3; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4wqk6wfcX4N4eeAVBl7dtswa4KdERnmnFq6t7rZZg0YFuP0bUF5akN6XkUFS3UC9jOb55Nari4w+0CHWZD1kobTxpyNRs4G2iz+DfEijAAiLLLQqym/kks+u78pZG0+3qCGDUf/jGwh74RSzlnWKZUuE1h9SYF8OIi5/9BtIrLIz/auamgqbC3OZ1ISwQ4nJpGPJ6Ssh5DhrBZw6E51cViWrhmQ7K6+AXI1pYJa5RD1tyNLgDCVLJ826AUeLT/pm43xfzYTWQgD/IV0tX79agbdD4sMFsIUulA5FWKqKLEdWJl5BfcN77WiptjWxET4rz2M2qyIRqdOaSDCrbtbuHz1HTkBGskjv2J/fbWXG26Sb2qlwCklfRDY8HzskncT1iplgJv5NV6rxyHNNrWeO5vJKICpjS/wRTWOh0w3XCQ7uU2L89AVbEn7NZNBVxAPWvrgmTjPBsnTUbbGpYFO/RA3PMMQ+hi9AkW2MZoxifHQ=
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-Network-Message-Id: cfd995cd-564f-4259-b151-08d7613a1630
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 15:17:20.1613 (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: KLpMtBF/0cn+3zhAjJGZYUalLLwueqtVmXTjvdEamyckrFdVssiZZ0HjzJ8V1Nld
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2109
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/WJvZHFs-vLDPJb_G5xZoolm0xtc>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17
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: Mon, 04 Nov 2019 15:17:28 -0000

See below (BV>).

- Bernie

-----Original Message-----
From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Alexandre Petrescu
Sent: Thursday, October 31, 2019 4:14 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

I discuss because comments are requested, but I do not oppose advancemet of this draft.

The questions I make below are more like brainstorming, because I do not use the mac-assign mechanism myself.

Le 30/10/2019 à 02:51, Tomek Mrugalski a écrit :
> Hi, This mail initiates a Working Group Last Call on two related
> IDs:
> 
> Link-Layer Addresses Assignment Mechanism for DHCPv6
> draft-ietf-dhc-mac-assign-01
> https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01
> 
> and
> 
> SLAP quadrant selection options for DHCPv6
> draft-ietf-dhc-slap-quadrant-01
> https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-01
> 
> Authors believe those drafts are ready for WGLC. Please post your 
> substantial comments and your opinion whether those are ready for 
> publication or not. If you have minor editorial comments, you may send 
> them to the authors directly.
> 
> Please post your comments by Nov. 17th.

draft says:
> DISCUSSION: A device may send its link-layer address in a LLADDR 
> option to ask the server to register that address to the client (if 
> available), making the assignment permanent for the lease duration.
> The client MUST be prepared to use a different address if the server  
> choses not to honor its hint.

I agree with the idea to request to register.

Which link-layer address may the device send in a LLADDR option?

Is it the link-layer address that was assigned previously by DHCP, or is it a temporary, or is it?

BV> This is whatever link-layer address that the device may have - such as a temporary address it may have generated. The server does not have to honor that request as the discussion points out.

The IoT devices and VMs  I have seen, if they have the capability to have a MAC address, then they already have something in there, like 0s, or like random bits, if not an IEEE-assigned address with OUI and so on.

Will this draft forbid these IoT devices and VMs to use their existing MAC addresses?

BV> No. I don't see how the draft could do that. Per above, if the device has an address in the non-global space, it can request to continue using it.

On another hand, can the MAC address that the device imposes (registers) to the DHCP server be used as a key to make the server always allocate the same IP address to the Client?

BV> That really is a policy issue for the DHCP server. There are many possibilities as to how this could be implemented such as:
1) Use an algorithm that given some input (such as client-id option), will always generate a stable mac address, OR
2) Once an address has been assigned, retain the binding between it and the client for a duration (either this is the valid lifetime or may be some additional lifetime beyond that that may not be communicated to the client)

> link-layer-len  Specifies the length of the link-layer-address field  
> (typically 6, for a link-layer-type of 1 (Ethernet)). A two octets 
> long field.

But the preceding figure says that the length is 128bits(?) precisely - there are no vertical dots, but vertical pipes '|'.  The rest of bits is padding 0s (leading? trailing?)?  MAC addresses longer than 128 bits arent accepted?

BV> 128 is never mentioned explicitly in this document. The figure using the vertical pipes in this manner is to say that this is a variable length field - there is no implication that of the size -- yes, it looks to be a multiple of 4 octets but that was just to make it easier to show the remaining fields (wrapping them between two rows makes them difficult to read). 

There are link-layers from IEEE that have lengths 16bit (short addresses in 802.15.4) and also 64bit (802.15.7 VLC Visible Light Comms).

BV> Correct. This is variable length field (link-layer-address is variable and depends on link-layer-type/link-layer-len).

> and may specify a specific address or address block as a hint for the 
> server.

I fully agree with the idea of requesting more than just one MAC address.  You call that a 'block'.  The question is how to represent (and implement) such a block.

BV> I'm not sure what the problem is here? 

> For example: link-layer-address: 02:04:06:08:0a and extra- addresses
> 3 designates a block of 4 addresses, starting from 02:04:06:08:0a
> (inclusive) and ending with 02:04:06:08:0d (inclusive).

Are the addresses ending in 0a, 0b, 0c and 0d each included in Figure3?
  In which field?

BV> Huh? A block is defined as the starting address plus the number of addresses. So, the 4 address ...0a, 0b, 0c, and 0d are represented by a starting address of ...0a and length of 3 (because it is "extra-addresses" - having 0 addresses assigned is useless).

Or only the starting address is included in full and the number of addresses in the field 'extra-addresses?

BV> See previous comment.

Shouldnt one rather encode the set of MAC addresses like the IPv6 address/plen notation? (rather than including fully each address).

BV> plen only allows allocating in powers of 2. 

What would be the relationship between a MAC block and an IP prefix?  In Prefix Delegation one would like to delegate always the same prefix to the same MAC address, to facilitate application continuity; with this address block concept here, would we talk about delegating an IP Prefix to a MAC block?

BV> Prefix delegation and mac address assignment are different and are used for different purposes. The mac-address is what the client will use to communicate at layer 2; prefix delegation is layer 3 issue. 

Finally, would one use a delegated MAC address to form an Interface ID and further prepend a prefix from RA to get a more privacy IP address?
(rather than using the built in MAC address that is centrally administered and has privacy risks).

BV> This is completely outside the scope of this document. Other documents cover how (or if) a link layer address is used for form an IPv6 address.

Alex


> 
> Cheers, Tomek
> 
> _______________________________________________ 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