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

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 30 Oct 2019 02:51:17 +0100

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.

Cheers,
Tomek

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Oct 2019 21:13:42 +0100

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:
> 
> publication or not. If you have minor editorial comments, you may 
> send them to the authors directly.
> 

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 
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>