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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 31 October 2019 20:13 UTC

Return-Path: <alexandre.petrescu@gmail.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 1683C12024E for <dhcwg@ietfa.amsl.com>; Thu, 31 Oct 2019 13:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 cJsxpFyp4TWt for <dhcwg@ietfa.amsl.com>; Thu, 31 Oct 2019 13:13:47 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D4D12022C for <dhcwg@ietf.org>; Thu, 31 Oct 2019 13:13:46 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9VKDi36002181 for <dhcwg@ietf.org>; Thu, 31 Oct 2019 21:13:44 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B9180206AA2 for <dhcwg@ietf.org>; Thu, 31 Oct 2019 21:13:44 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AF63D203A2B for <dhcwg@ietf.org>; Thu, 31 Oct 2019 21:13:44 +0100 (CET)
Received: from [10.11.240.12] ([10.11.240.12]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9VKDhJo009032 for <dhcwg@ietf.org>; Thu, 31 Oct 2019 21:13:44 +0100
To: dhcwg@ietf.org
References: <c9976d83-7243-cf44-a9c6-ff858afb5247@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <87cdc523-58ca-1681-31ca-f1733f8aa3d2@gmail.com>
Date: Thu, 31 Oct 2019 21:13:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0
MIME-Version: 1.0
In-Reply-To: <c9976d83-7243-cf44-a9c6-ff858afb5247@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/8qGdlMRayimNkc6q0xMRlXaPo5A>
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: Thu, 31 Oct 2019 20:13:49 -0000

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?

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?

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?

> 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?

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).

> 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.

> 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?

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

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

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?

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).

Alex


> 
> Cheers, Tomek
> 
> _______________________________________________ dhcwg mailing list 
> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>