Link-Layer Address Assignment Mechanism for DHCPv6
draft-ietf-dhc-mac-assign-09

Should a client be able to request multicast addresses?

I think it might be good to restrict clients to only request unicast addresses.

No comments beyond those already entered by others.

Section 1:
* "... -  more details are in Appendix A." -- This should be its own sentence.

Section 3:
* "... typically 6 octets long." -- s/6/six/ (and for all numbers below 10 in prose; more below)
* "... (extra) addresses/ A single address ..." -- that slash should be a period

Section 4.3:
* "... may specify a specific ..." -- maybe "include a specific"?
* "... with offered address or addresses." -- put "an" before "address"
* Can we just refer to Figure 1 over in RFC 8415 rather than copying it here?
* "An administrator may make the address assignment permanent by ..." -- this is already stated earlier in the same section

Section 5:
* In the second paragraph, two consecutive sentences start with "Therefore".  I suggest just dropping the first instance.

Section 8:
* "... expand the address block - once ..." -- make that an em dash, or a new sentence

Section 10.1:
* "A 4-octet field ..." -- suggest "four-octet" (three instances in this section, more in 10.2)

Section 10.2:
* I suggest that naming the IANA registry here is sufficient; the URL isn't needed.  (What if it were to change?)
* "A 2-octet field ..." -- suggest "two-octet"

Section 11:
* "Ethernet / IEEE ..." -- somewhere earlier in the document, the liberal spacing here caused funny wrapping to occur, so I suggest "Ethernet/IEEE"

Section 12:
* Same comment about the registry URLs here as above.

The reviews of others have already captured my feedback.

I support Ben Kaduk’s second DISCUSS item

I support Robert Wilton’s DISCUSS position adding language to the implications of address reuse.

Please review and respond to the SECDIR review (thanks for the review Sean)

[ Thank you for addressing my DISCUSS, I've cleared.]

Thank you for writing this -- I *do* like this document, and agree that it solves a real problem (e.g: http://grouper.ieee.org/groups/802/PrivRecsg/email/msg00164.html ), but would like to make sure that it is deployable without causing sadness...

I think it would be useful to also add some text around policy limits / DoS.
As examples, would you expect that this would be enabled on "regular" user interfaces (e.g at my local coffee shop), or is it more designed for datacenters and IoT VLANs? Either way, should a device be able to ask for 00:00:00:00:00:01 and 2^48-2 addresses? The document does say things like: "In particular, the server may send a different starting address than requested, or grant a smaller number of addresses than requested.", but it might be nice to also include something like "implementations should allow configuration of the maximum number of addresses to allocate" or something similar (yes, an attacker could keep coming back and looking like a new device, but...)

(0) I support Ben's DISCUSS.


(1) An informative reference to the "birthday paradox" would be nice.


(2) §4.2

   Note that a client that operates as above that does not have a
   globally unique link-layer address on any of its interfaces MUST NOT
   use a link-layer based DUID (DHCP Unique Identifier), i.e., DUID-LLT
   or DUID-LL, for its client identifier.  As of this writing, this
   means such a device MUST use a DUID-EN or DUID-UUID (though new DUID
   types may be defined in the future).  For more details, refer to
   Section 11 of [RFC8415].

Given that "new DUID types may be defined in the future", and assuming that it applies to any type of DUID, it may be a good idea to generalize/simplify this paragraph.

NEW>
   A client that operates as above that does not have a globally unique
   link-layer address on any of its interfaces MUST NOT use a link-layer based
   DUID (DHCP Unique Identifier).  For more details, refer to Section 11 of
   [RFC8415].


(3) s/allocates block/allocates a block


(4) §7:

   The client MUST be able to handle an Advertise message containing a
   smaller number of addresses, or an address or addresses different
   from those requested.
   ...
   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.

What does "MUST be able to handle" mean?  Being able to handle something doesn't sound normatively enforceable.  I'm guessing that maybe the client MUST accept the allocation...but this interpretation might be in conflict with §9.  Ben offered other suggestions in his review. 


(5) §10.1  As far as I can see, some of the fields (IAID, T1, T2) (should) have the same definition as in rfc8415.  To avoid duplicating the definition, or deviating from it, consider simply pointing at the definition there.


(6) s/If the time at which the addresses in an IA_LL are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0./If the server sets T1 and T2 to 0, then the time at which the addresses in an IA_LL are to be renewed is to be left to the discretion of the client.


(7) §10.1: "the client MUST use the values in the T1 and T2 fields for the T1 and T2 times, unless those values in those fields are 0."  This sounds as if 0 is not valid.  Maybe "MUST set" would be better.


(8) I-D.ietf-dhc-slap-quadrant and IEEEStd802c-2017 should be Normative references.

Amazingly, “MAC” is not flagged as well-known in the RFC Editor abbreviations list (we probably should suggest that “MAC address” be so flagged), so it should be expanded on first use in the Introduction.

— Section 1 —

   a link-layer
   assignment mechanisms allows for conflicts to be avoided

Nit: “mechanism”, singular.

   types of resources (non-temporary addresses, temporary addresses,
   prefixes, but also many options)

The “but” feels wrong here.  I think I would change “but also” to “as well as”.

   and has necessary infrastructure
   (numerous server and client implementations, large deployed relay
   infrastructure, supportive solutions, like leasequery and failover)
   to maintain such assignment

Two things here: you used “allocate” before, not “assign”, so “such assignment” doesn’t work.  And the parenthetical is too long for it to split the sentence as it does:

NEW
   and has necessary infrastructure to maintain such allocation
   (numerous server and client implementations, large deployed relay
   infrastructure, supportive solutions like leasequery and failover)
END

   specified an optional specification (IEEE 802c) that divides this

“specified a specification” is awkward.  It’s probably better as “published an optional specification”.  Also, why isn’t “IEEE 802c” a proper reference citation?  You do have the reference, and it’s cited in Appendix A.  Why not cite it here?

— Section 4.1 —

   block), to be then assigned for use to the final end-devices.

I would say, “to be then assigned for use by the final end-devices,” or, “to be then assigned to the final end-devices for their use.”

   One
   relevant example of scenario of application of this mode is large
   scale virtualization.

“example of scenario of application of this mode” doesn’t work.  How about, “Large-scale virtualization is one application scenario for proxy client mode.”?

   hypervisor is likely to increase its addresses usage.

Nit: “address usage”

— Section 4.2 —

   This mode is used when an entity acts as a DHCP client and requests
   available DHCP servers to assign one or more addresses (an address
   block) for its own use.

I don’t think you mean “for its own use”, which would be referring to one of the servers.  I think you mean that the block is for the client’s use, so just “for its use.”

— Section 4.3 —

   An administrator may also disable the need for the
   renewal mechanism by setting the T1 and T2 values to infinity.

You already said this a few paragraphs earlier.  Maybe check the organization of this section?

   small footprint devices may choose to not support it.

Nit: hyphenate “small-footprint”.

— Section 6 —

   A client sets the extra-addresses field to either 0 for a single
   address or to the size of the requested address block minus 1.

Think of “either” and “both” as parentheses.  Here, the word “to” is outside the parentheses and shouldn’t be repeated inside.  So make it “to either 0 for a single address or the size...” or “either to 0 for a single address or to the size...”.

— Section 7 —

   or an address or addresses different
   than those requested.

Nit: either “different from” (US usage) or “different to” (UK usage), but not “different than”.

— Section 13 —

   There is a possibility of the same link-layer address being used by
   more than one device if not all parties on a link use this mechanism
   to obtain a link-layer address from the space assigned to the DHCP
   server.  It is also possible that a bad actor purposely uses a
   device's link-layer address.

It seems that it would be worth adding something about what the consequences of that are.

Might it also be worth mentioning that a malicious client could request a very large block of addresses and thus deplete the supply available to legitimate clients?  If so, noting possible defense against that (such as a server policy about maximum address block size) might also be useful.

Thank you for the updates addressing my discuss and comment points; I
just have a couple remaining suggestions.

Section 4.2

   Note that a client that operates as above that does not have a
   globally unique link-layer address on any of its interfaces MUST NOT
   use a link-layer based DUID (DHCP Unique Identifier).  For more

Is this MUST NOT scoped to the interface(s) in question?

Section 10.1

   The Identity Association for Link-Layer Addresses option (IA_LL
   option) is used to carry an IA_LL option, the parameters associated
   with the IA_LL, and the address blocks associated with the IA_LL.

If I'm reading RFC 8415 correctly, the typical construction would be
more like "Identity Associateion for Link-Layer Addresses (IA_LL)
option is used to carry an IA_LL, [...]".

I  found this document to be especially readable. Thanks!

Nits:
Section 5. The phrase “especially in the hypervisor scenario is used twice in two sentences.

Section 7. Missing word in brackets:
...Advertise message [with] an IA_LL option..
...allocates [a] block...
...Solicit, [it] may receive a Reply

Sec 10.2. It would also be worthwhile to repeat here what extra-addresses means in a packet from the client, since you do so for the server.

Previous discuss issues that have been cleared:

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.


Nob blocking comments:

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.