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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Mon, 08 June 2020 04:28 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0CF3A0A3B; Sun, 7 Jun 2020 21:28:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dhc-mac-assign@ietf.org, dhc-chairs@ietf.org, dhcwg@ietf.org, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, Ian Farrer <ianfarrer@gmx.com>, ianfarrer@gmx.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159159050144.17160.2937263097536871303@ietfa.amsl.com>
Date: Sun, 07 Jun 2020 21:28:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/-4t_pFDfREjHHeUytcgoQycMvrc>
Subject: [dhcwg] Benjamin Kaduk's Discuss on draft-ietf-dhc-mac-assign-07: (with DISCUSS and COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Jun 2020 04:28:22 -0000

Benjamin Kaduk 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:


I have a couple points that might require a bit of discussion, but I
expect to be pretty easy to resolve:

(1) Can we double-check this text in Section 10.1:

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

I am pretty sure that the "is used to carry one or more IA_LL options"
should actually be talking about IA_LLADDR options.  But if I'm wrong,
and this is saying that IA_LL can carry IA_LL, we should have a lot more
discussion about this recursive structure and how to interpret it.

(2) I'd also like to have a bit of discussion about the "direct client
mode scenario" (Section 4.2).  The current text implies that a device
might use DHCPv6 on a single interface to request addresses for each
local interface and then use the returned allocation from the one
interface as link-layer addresses on the other interfaces.  While we do
say that this "typically means one address per device", we still talk
about the more general case, and I'm not sure I understand when it makes
sense.  Given that (as Section 11 notes), "[l]ink-layer addresses are
typically specific to a link", and a multi-interface client may not a
priori know that any given set of its interfaces are on the same link,
it seems like this scenario is introducing risk that we use an allocated
address outside of the scope of authority from which it was allocated,
risking collision.  (While the security considerations rightly note that
coping with collision is something that nodes need to be prepared to do
anyway, we don't need to be encouraging it.)

Without some discussion of (e.g.) a link aggregation scenario where a
client is bonding multiple physical interfaces into a higher-capacity
logical interface, I don't think we should mention this multi-interface
scenario at all.


The four-message DHCP exchange (Solicit/Advertise/Request/Reply) has the
server provisionally provide specific values in the Advertise that are
not committed until the Reply is generated.  There seems to be a need
for some statement about required (or not) consistency between values in
Advertise and Reply, and what level of checking the client needs to
perform, but I didn't find such discussion in a quick spot-check of RFC
8415.  I do see some notes in this document, e.g., in Section 7, but I
might consider adding a more general discussion in the security
considerations, if there's not preexisting text in 8415 that would cover
this topic.  Could you point me to anything in 8415 that seems related?


   In certain environments, e.g. large scale virtualization deployments,

nit: comma after (and before) "e.g."

   Therefore an allocation mechanism is required.  This draft proposes
   an extension to DHCPv6 that allows a scalable approach to link-layer
   address assignments.

I would suggest adding another qualifier to "link-layer address
assignments" here; especially in light of the IOT-Dir review, I do not
think that we are attempting to claim that (e.g.) manufacturer-assigned
MAC addresses burned in to ethernet chips do not scale, though the text
as written implies such a claim.  I'm not sure if "randomized" is the
best possible qualifier, but may suffice.

Section 1

   There are several new deployment types that deal with a large number
   of devices that need to be initialized.  One of them is a scenario

nit: I'm not sure how well "new deployment types" will age.

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

I'd suggest giving some example numbers for number-of-VMs and
probability of collision.

   The huge number of such devices would likely exhaust a vendor's OUI
   (Organizationally Unique Identifier) global address space, and while

It's probably worth a reminder of how big that per-vendor space is.

   avoided inside an administrative domain.  For those reasons, it is
   desired to have some form of authority that would be able to assign
   locally unique MAC addresses.

I will probably touch on the use of "authority" again later: it seems
that at least in some cases the only "authority" involved is "the
network has allowed the sending of a DHCPv6 response", which is not
always going to actually indicate any level of authority.

   The IEEE originally set aside half of the 48-bit MAC Address space
   for local use (where the U/L bit is set to 1).  In 2017, the IEEE
   published an optional specification ([IEEEStd802c-2017]) that divides
   this space into quadrants (Standards Assigned Identifier, Extended
   Local Identifier, Administratively Assigned Identifier, and a
   Reserved quadrant) - more details are in Appendix A.

I suggest clarifying to "further divides this local-use space into

   The IEEE is also working to specify protocols and procedures for
   assignment of locally unique addresses (IEEE 802.1cq).  This work may
   serve as one such protocol for assignment.  For additional
   background, see [IEEE-802-Tutorial].

This sounds an awful lot like "IEEE and IETF are working on the same
problem".  I trust there has been ample liaising and cross-pollination
to avoid surprises and duplication of effort.

Section 3

   The DHCP terminology relevant to this specification from [RFC8415]
   applies here.

I suggest a note that what follows is (includes?) additional
definitions, since (e.g.) "address block" is not defined in 8415.

   address block A number of consecutive link-layer addresses.  An
                 address block is expressed as a first address plus a
                 number that designates the number of additional (extra)
                 addresses/ A single address can be represented by the
                 address itself and zero extra addresses.

Just to check: there is no requirement for alignment or for the number
of extra addresses to be one less than a power of two?

Section 4.1

   mode.  In such environments the governing entity is often called a
   hypervisor and is frequently required to spawn new VMs.  The

nit: we don't really provide a clear explanation/definition of
"governing entity"; we only talk about "an entity" previously, with no
mention of governance.

   pointing out the cumulative nature of this scenario.  Over time, the
   hypervisor is likely to increase its address usage.  Some obsolete
   VMs will be deleted and their addresses will be eligible for reuse
   for new VMs.

Would it be appropriate to say "potentially eligible" or "eventually
eligible" to account for the risk of other entities having cached the
previous validity of the address(es) in question?

Section 4.3

   address block as a hint for the server.  Each available server
   responds with an Advertise message with offered address or addresses.
   The client then picks the best server, as governed by [RFC8415], and
   will send a Request message.  The target server will then assign the

note: the phrase "best server" is not used by RFC 8415, and the only
relevant usage of "best" that I found was in Section 18.2, which refers
to the "best configuration available" in a case where only a subset of
the requested functionality is available.  So I don't think the current
quoted text is an adequate reference for the intended behavior.  Is it,
perhaps, intended to refer to the "Preference" mechanism discussed in
Section 18.2.1 of RFC 8415?

   Clients implementing this mechanism SHOULD use the Rapid Commit
   option as specified in Section 5.1 and 18.2.1 of [RFC8415].

I think adding the justification text suggested in response to the
INT-dir review would be useful.

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

This feels fairly redundant with the text before Figure 1 about infinite

   Devices supporting this proposal MAY support the reconfigure
   mechanism, as defined in Section 18.2.11 of [RFC8415].  If supported
   by both server and client, this mechanism allows the administrator to
   immediately notify clients that the configuration has changed and
   triggers retrieval of relevant changes immediately, rather than after
   the T1 timer elapses.  Since this mechanism requires implementation
   of Reconfigure Key Authentication Protocol (See Section 20.4 of
   [RFC8415]), small-footprint devices may choose to not support it.

nit: I suggest disambiguating "this mechanism" to refer to the
reconfigure mechanism, and not the link-layer address assignment
mechanism that's the core focus of this document.

Section 5

   hypervisors, possibly even only one.  However, over time the number
   of addresses requested by the hypervisor(s) will likely increase as
   new VMs are spawned.

I'm not sure the intent of the "increase over time" here -- if we
recycle addresses as VMs are destroyed, then surely the number of
addresses allocated to a given hypervisor will saturate at the capacity
of that hypervisor?

Section 7

   requested.  The server sends back an Advertise message an IA_LL
   option containing an LLADDR option that specifies the addresses being
   offered.  If the server is unable to provide any addresses it MUST
   return the IA_LL option containing a Status Code option (see
   Section 21.13 of [RFC8415]) with status set to NoAddrsAvail.

This is an interesting statement, as it could be read as trying to
require *all* servers (even those that don't implement this document) to
return IA_LL+NoAddrsAvail in this case, not just servers that implement
this document.

   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.

In some sense it seems like this generic class of behavior should be
part of 8415 and "not need to be repeated here" (though, to be clear, I
am happy to see these statements and would like them to remain).
I would also suggest to note that (e.g.) "the client MUST NOT use
addresses included in an Advertise message but not confirmed in a Reply
for link-layer traffic" and "the client MAY use such addresses in
deciding what server to use" and/or "the client MAY discard such an
allocation and re-send a request to a different server as a result.

Section 8

   If the requesting client needs additional addresses -- e.g., in the
   hypervisor scenario because addresses need to be assigned to new VMs
   -- the simpler approach is for the requesting device to keep the
   address blocks as atomic once "leased".  Therefore, if a client wants
   more addresses at a later stage, it SHOULD send an IA_LL option with
   a different IAID to create another "container" for more addresses.

side note: I guess I'm not sure what the client would do other than the
behavior recommended by the "SHOULD" -- other than "give up and be sad",
it seems like the only other choice would be to send an IA_LL with the
same IAID, which seems unlikely to work.  This is a side note because I
don't think there's a useful change to make to the text; I'm mostly just

   If the client is unable to Renew before the T2 timer elapses, it
   starts sending Rebind messages as described in 18.2.5 of [RFC8415].

nit: this reference lacks a "Section" and is not htmlized into a
section-link.  I mostly expect that in the v2-->v3 conversion the RFC
Editor will make it DTRT, if you want to just leave it to them.

Section 9

   The client may decide to release a leased address block.  A client
   MUST release the whole block in its entirety.  A client releases an
   address block by sending a Release message that includes the IA_LL

nit: I think this is more correct as "an IA_LL option" (but the
following "the LLADDR option", not quoted, is okay as-is).

Section 10

   This mechanism uses an approach similar to the existing mechanisms in
   DHCP.  There is one container option (the IA_LL option) that contains
   the actual address or addresses, represented by an LLADDR option.
   Each such option represents an address block, which is expressed as a
   first address with a number that specifies how many additional
   addresses are included.

Is the "each such option" each LLADDR option or each IA_LL option?

Section 10.1

   IAID            The unique identifier for this IA_LL; the IAID must
                   be unique among the identifiers for all of this
                   client's IA_LLs.  The number space for IA_LL IAIDs is

To check my understanding: "this client" is identified by the DUID here,
right?  (No need to change the text, I think, if that's correct.)

   T1              The time at which the client should contact the
                   server from which the addresses in the IA_LL were
                   obtained to extend the valid lifetime of the
                   addresses assigned to the IA_LL; T1 is a time

I would strongly prefer to reuse the "time interval after which"
language from RFC 8415 (for T2, as well); the current text refers to T1
as an (absolute, by implication) "time" here but clarifies it to be a
"time duration" (or "time interval") later on.  Absolute and relative
time are different units and should not be intermingled so.

Section 10.2

   option-len      12 + link-layer-len field (typically 6) + length of
                   LLaddr-options field.  Assuming a typical link-layer
                   address of 6 is used and there are no extra options,
                   length should be equal to 18.

I suggest s/should be/would be/; there's no optionality in the described

   link-layer-len  Specifies the length, in octets, of the link-layer-
                   address field (typically 6, for a link-layer-type of
                   1 (Ethernet)).  A 2-octet field containing an
                   unsigned integer.

Is there something to say about being a function of the link-layer-type
vs. link layers with variable-length addresses?

   link-layer-address  Specifies the link-layer address that is being
                   requested or renewed, or a special value to request
                   any address.  For a link-layer type of 1 (Ethernet /
                   IEEE 802 48-bit MAC addresses), see Section 6 for
                   details on these values.  In responses from a server,
                   this value specifies the first address allocated.

What's the procedure for specifying the "special value" for other
address types?  (Absent any discussion in this document I am forced to
assume "RFC that Updates this one".)
Also, doesn't the linked IANA registry claim that type 6 is for IEEE 802
Networks, not type 1?

Section 13

We should probably say something about how a node using this mechanism
would be confident that the DHCPv6 server is authorized to perform
link-layer address assignment (e.g., out of band configuration) and/or
something about trusting the network to only allow DHCPv6 responses from
authorized DHCPv6 servers.

   See [RFC8415] and [RFC7227] for the DHCP security considerations.

RFC 7227 says that authors of documents defining new DHCP options are
"strongly advised to explicitly define validation measures" for
recipients of such options.  I do not see any such validation measures
specified in this document; why is there no need to do so?

   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 an address from the space assigned to the DHCP server.
   Note that this issue would exist on these networks even if DHCP were
   not used to obtain the address.  See [IEEE-802.11-02-109r0] for
   techniques that can be used on 802.11 networks to probe for and avoid

I agree with the directorate reviewer that the use of a powerpoint slide
deck as a reference is surprising, though this reference does seem
superior to no reference at all.

Section 14

I think we should say something about how allocating addresses as a
sequential block of adjacent addresses can lead to assumptions that
numerically close-by addresses are related in some way (e.g., on the
same VM hypervisor).  For the intended deployment models, I do not think
the risk of such correlation necessitates a more complicated allocation
scheme, but I do think it's important to document the risk (for example,
if it became more relevant for some future use case ).

   assigned address.  Additional mechanisms, such as the ones described
   in [RFC7844] can also be used.

Please say something about what the goal of these mechanisms would be
(e.g., "preserving privacy" or "preserving anonymity").