Subject: [dhcwg] Robert Wilton's Discuss on draft-ietf-dhc-mac-assign-07: (with DISCUSS and COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 08 Jun 2020 04:08:08 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-dhc-mac-assign-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thank you for this document.  Mostly I found this document to be straight
forward to read, but there are a few areas that were unclear to me, that could
probably help being clarified.

Hopefully none of these are too difficult to address, or they may turn out not
to be issues at all ...

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.

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.

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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Introduction

   Typically the new VM instances are assigned a random link-layer (MAC)
   address, but that does not scale well due to the birthday paradox.

Perhaps either have a reference to birthday paradox, or briefly describe (in a
sentence) what the paradox is.

4.3. Mechanism Overview

Contains both:

   This mechanism can be administratively disabled by the server sending
   "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]).

And

   An administrator may make the address assignment permanent by
   specifying use of infinite lifetimes, as defined in Section 7.7 of
   [RFC8415].

Perhaps these sentences could be amalgamated?

7.  Requesting Addresses

    The client MUST be able to handle a Reply message containing a smaller
    number of addresses, or an address or addresses different from those
    requested.

Perhaps clarify whether the "smaller number of addresses" relates to the
initial request from the client, or the value received by the client from the
server in teh advertise message.  E.g. could a server "advertise" a block of
100 addresses, but then only "reply" with a block of 50 addresses?

8. Renewing Addresses

IAID is used before it defined.  Perhaps either add it to the terminology, or
reference where it is defined when it is first used?

10.1
I found the subtle distinction between "IA_LL option" vs "IA_LL-options" to
probably be a bit more confusing than necessary.  Possibly always refering to
the "IA_LL_OPTION option" vs "IA_LL-options field" would add clarify, or
perhaps rename "IA_LL-options" to "IA_LL-suboptions".  The same comment
obviously applies to the LLADDR option definition as well.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 8 Jun 2020 15:00:21 +0000

Hi,

One more question that I thought of when reviewing the slap-quadrant draft:

Does draft-ietf-dhc-mac-assign only assign unicast MAC addresses?  I would assume so, but this doesn't appear to be stated anywhere, and it would probably be helpful if it was.

Regards,
Rob

-----Original Message-----
From: iesg <[email-masked]> On Behalf Of Robert Wilton via Datatracker
Sent: 08 June 2020 12:08
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Tomek Mrugalski <[email-masked]>; [email-masked]
Subject: Robert Wilton's Discuss on draft-ietf-dhc-mac-assign-07: (with DISCUSS and COMMENT)

Hi,

9. Releasing Addresses

1. Introduction

4.3. Mechanism Overview

Contains both:

And

7.  Requesting Addresses

8. Renewing Addresses

10.1

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 8 Jun 2020 15:54:26 +0000

Hi:

While the mac-assign is focused on mac-addresses, we called it link-layer address assignment as other documents COULD specify using it for other link-layers and we have the ability to support any link layers (and of any size). There are some specifics (such as whether all 0's address request means assign me whatever you want -- though likely that is the case for almost all link-layers?) that may need to be specified in such a document. But likely it could be used "as is" without any additional documents for other link-layers.

The slap-quadrant is mac-address specific so that is just for mac-addresses.

- Bernie

On 6/8/20, 11:01 AM, "Rob Wilton (rwilton)" <[email-masked]> wrote:

    Hi,

    Regards,
    Rob

    -----Original Message-----
    From: iesg <[email-masked]> On Behalf Of Robert Wilton via Datatracker
    Sent: 08 June 2020 12:08
    To: The IESG <[email-masked]>
    Cc: [email-masked]; [email-masked]; [email-masked]; Tomek Mrugalski <[email-masked]>; [email-masked]
    Subject: Robert Wilton's Discuss on draft-ietf-dhc-mac-assign-07: (with DISCUSS and COMMENT)

    Hi,

    9. Releasing Addresses

    1. Introduction

    4.3. Mechanism Overview

    Contains both:

    And

    7.  Requesting Addresses

    8. Renewing Addresses

    10.1

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 8 Jun 2020 16:00:26 +0000

Hi Bernie,

Okay, but in the specific case where MAC addresses are being handed out, presumably these should only be unicast MAC addresses?  And what would happen if a client request a block of multicast MAC addresses?

Thanks,
Rob

-----Original Message-----
From: Bernie Volz (volz) <[email-masked]> 
Sent: 08 June 2020 16:54
To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Tomek Mrugalski <[email-masked]>; [email-masked]; The IESG <[email-masked]>
Subject: Re: Robert Wilton's Discuss on draft-ietf-dhc-mac-assign-07: (with DISCUSS and COMMENT)

Hi:

- Bernie

    Hi,

    Regards,
    Rob

    -----Original Message-----
    From: iesg <[email-masked]> On Behalf Of Robert Wilton via Datatracker
    Sent: 08 June 2020 12:08
    To: The IESG <[email-masked]>
    Cc: [email-masked]; [email-masked]; [email-masked]; Tomek Mrugalski <[email-masked]>; [email-masked]
    Subject: Robert Wilton's Discuss on draft-ietf-dhc-mac-assign-07: (with DISCUSS and COMMENT)

    Hi,

    9. Releasing Addresses

    1. Introduction

    4.3. Mechanism Overview

    Contains both:

    And

    7.  Requesting Addresses

    8. Renewing Addresses

    10.1

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 8 Jun 2020 17:09:31 +0000

Hi:

Yes, these are assumed to be unicast as that is what IEEE802c did - divide up the unicast address space. While we discussed it, we saw no need to assign multicast.

> And what would happen if a client request a block of multicast MAC addresses?

First, there's no clear way for a client to ask for a multicast address unless the client were to request a specific assignment (start + count). We did NOT call out that 01:00:00:00:00:00 would be used to request a multicast address block. And, if a client where to ask, it would depend on what was configured on the server so this mechanism COULD be used to provide multicast (for specific block requests),
Second, the server would probably ignore the requested multicast block since unless someone configured that (multicast) address space on the server, it would not be available. The client would be given something that's available.

The one issue this brings up is that if large blocks are defined on the server (so that a block crosses the 41st bit of the 48-bit address - i.e., into the first octet), the server would have to make sure that any assignments do not have the LSB (M-bit) set as that would indicate a multicast-address. This is because of the way the address bits are laid out. I think we could easily add something (likely in Section 6) like the following:

--- Begin of added text at end of section:

For servers, configured 48-bit mac-address blocks MUST NOT be allowed to span the 41st bit (first octet) of the 48-bit address as otherwise the server and clients would need special handling to account for the layout of the mac-address and the location of the M-, X-, Y-, and Z- bits (see Appendix A). While up to 46 bits could theoretically be available for assignment in the unicast local assignment space, this would require special handling in servers and clients to account for the location of the M- and X-bits (and possibly the Y- and Z-bits) and it does not seem worth adding this complexity to clients and servers.

--- End of added text

I think that's a good catch - though as a server implementer, I would have limited the blocks to be <= /40 and used much of the IPv6 internals (that was one reason DHCPv6 seemed like a good design as you could pretty much think about this as assigning IPv6 addresses from /88 to /128 prefix pools).

BTW: This really is no different than the IPv6 address assignment - nothing in RFC8415 says anything about unicast vs multicast for IA_NA/IA_TA (IAADDR) options. The semantics for address could change over time based on the IPv6 address architecture.

- Bernie

-----Original Message-----
From: Rob Wilton (rwilton) <[email-masked]> 
Sent: Monday, June 8, 2020 12:00 PM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Tomek Mrugalski <[email-masked]>; [email-masked]; The IESG <[email-masked]>
Subject: RE: Robert Wilton's Discuss on draft-ietf-dhc-mac-assign-07: (with DISCUSS and COMMENT)

Hi Bernie,

Thanks,
Rob

-----Original Message-----
From: Bernie Volz (volz) <[email-masked]> 
Sent: 08 June 2020 16:54
To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Tomek Mrugalski <[email-masked]>; [email-masked]; The IESG <[email-masked]>
Subject: Re: Robert Wilton's Discuss on draft-ietf-dhc-mac-assign-07: (with DISCUSS and COMMENT)

Hi:

- Bernie

    Hi,

    Regards,
    Rob

    -----Original Message-----
    From: iesg <[email-masked]> On Behalf Of Robert Wilton via Datatracker
    Sent: 08 June 2020 12:08
    To: The IESG <[email-masked]>
    Cc: [email-masked]; [email-masked]; [email-masked]; Tomek Mrugalski <[email-masked]>; [email-masked]
    Subject: Robert Wilton's Discuss on draft-ietf-dhc-mac-assign-07: (with DISCUSS and COMMENT)

    Hi,

    9. Releasing Addresses

    1. Introduction

    4.3. Mechanism Overview

    Contains both:

    And

    7.  Requesting Addresses

    8. Renewing Addresses

    10.1