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

[Ballot comment]
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.

[Ballot comment]
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.


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

[Ballot comment]
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, [...]".

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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)

[Ballot comment]
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.

[Ballot comment]
(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.

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

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

[Ballot discuss]
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
  IA_LL.

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.

[Ballot comment]
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?

Abstract

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

  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
  [RFC8415].

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

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

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

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

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

[Ballot comment]
Thank you for this useful and easy to read document.

Please also address the IoT Directorate review by Samita Chakrabarti and Jaime Jimenez:
https://datatracker.ietf.org/doc/review-ietf-dhc-mac-assign-06-iotdir-lc-chakrabarti-2020-05-11/
https://datatracker.ietf.org/doc/review-ietf-dhc-mac-assign-06-iotdir-lc-jimenez-2020-06-03/

as well as the INT directorate review by Tatuya Jinmei :
https://datatracker.ietf.org/doc/review-ietf-dhc-mac-assign-06-intdir-lc-jinmei-2020-06-03/

Regards

-éric

[Ballot comment]
[ 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...)

[Ballot discuss]
Be ye not afraid -- these should be easy to address.

I have some concerns about this document -- much of my unease isn't specifically about the document itself, but rather the impact that deploying this on a wide scale may create. Much of my concerns can probably be addressed by sprinkling on some weasel-words / "you could shoot yourself in the foot if not careful" language.

Unless I've horribly misunderstood, in the direct client mode, a device comes up, connects to a switch and then changes its MAC address to the DHCP assigned one. This may interact poorly with:
a: switches with small CAM tables (sometimes deployed in DCs)
b: devices with configured maximum MACs per port, common in enterprises (e.g: https://www.cisco.com/c/m/en_us/techdoc/dc/reference/cli/nxos/commands/l2/switchport-port-security-maximum.html )
c: 802.1X (which is often configured to only allow a single MAC per interface / VLAN)
d: switches which do things like DHCP snooping.
Again, I do realize that most of these issues are not directly the result of this technique, but implementing / deploying this makes it more likely that devices will come up with a temp address and then pivot to an assigned one, and I'd like to see some operational warnings...

[Ballot comment]
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...)

[Ballot comment]
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.

Note added 'For information, this MAC-assign document is linked to draft-ietf-dhc-slap-quadrant-08 (currently in IETF Last call). Probably better to read them in a row: first MAC assign then SLAP.'

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dhc-mac-assign-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Option Codes registry on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

https://www.iana.org/assignments/dhcpv6-parameters/

two, new option codes are to be registered as follows:

Value: [ TBD-at-Registration ]
Description: OPTION_IA_LL
Client ORO: No
Singleton Option: No
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: OPTION_LLADDR
Client ORO: No
Singleton Option: No
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-05-19):

From: The IESG
To: IETF-Announce
CC: draft-ietf-dhc-mac-assign@ietf.org, Ian Farrer , dhc-chairs@ietf.org, ianfarrer@gmx.com, Tomek Mrugalski , evyncke@cisco.com, dhcwg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Link-Layer Addresses Assignment Mechanism for DHCPv6) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'Link-Layer Addresses Assignment
Mechanism for DHCPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  In certain environments, e.g. large scale virtualization deployments,
  new devices are created in an automated manner.  Such devices
  typically have their link-layer (MAC) addresses randomized.  With
  sufficient scale, the likelihood of collision is not acceptable.
  Therefore an allocation mechanism is required.  This draft proposes
  an extension to DHCPv6 that allows a scalable approach to link-layer
  address assignments.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document defines a new DHCPv6 based mechanism for leasing link-layer addresses to clients.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document extends the DHCPv6 protocol to include the leasing of link-layer addresses. It defines both a direct client mode, whereby a client requests a LL addresses, or block of addresses, intended for configuration on its own interface(s). Proxy client mode allows a block of addresses to be requested by a client (e.g. a hypervisor), which will then be used for configuring end-devices. One application for this function are large scale VM deployments, where the likelihood of a MAC address collision is not acceptable (due to the birthday paradox). Two new DHCPv6 options are defined for this purpose.

Working Group Summary:

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy have been raised during the authoring or review process.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Erik Vyncke is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document, the result of the WGLC was determined as successful by Suresh Krishnan (responsible AD at the time of the WGLC).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-slap-quadrant-04, but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of new DHCPv6 option codes for the two new DHCPv6 options that are defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document defines a new DHCPv6 based mechanism for leasing link-layer addresses to clients.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document extends the DHCPv6 protocol to include the leasing of link-layer addresses. It defines both a direct client mode, whereby a client requests a LL addresses, or block of addresses, intended for configuration on its own interface(s). Proxy client mode allows a block of addresses to be requested by a client (e.g. a hypervisor), which will then be used for configuring end-devices. One application for this function are large scale VM deployments, where the likelihood of a MAC address collision is not acceptable (due to the birthday paradox). Two new DHCPv6 options are defined for this purpose.

Working Group Summary:

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy have been raised during the authoring or review process.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Erik Vyncke is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document, the result of the WGLC was determined as successful by Suresh Krishnan (responsible AD at the time of the WGLC).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-slap-quadrant-04, but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of new DHCPv6 option codes for the two new DHCPv6 options that are defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document defines a new DHCPv6 based mechanism for leasing link-layer addresses to clients.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document extends the DHCPv6 protocol to include the leasing of link-layer addresses. It defines both a direct client mode, whereby a client requests a LL addresses, or block of addresses, intended for configuration on its own interface(s). Proxy client mode allows a block of addresses to be requested by a client (e.g. a hypervisor), which will then be used for configuring end-devices. One application for this function are large scale VM deployments, where the likelihood of a MAC address collision is not acceptable (due to the birthday paradox). Two new DHCPv6 options are defined for this purpose.

Working Group Summary:

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy have been raised during the authoring or review process.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Suresh Krishnan is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Awaiting Tomeck's response.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document, the result of the WGLC was determined as successful by Suresh Krishnan (responsible AD).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-slap-quadrant-04, but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of new DHCPv6 option codes for the two new DHCPv6 options that are defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document defines a new DHCPv6 based mechanism for leasing link-layer addresses to clients.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document extends the DHCPv6 protocol to include the leasing of link-layer addresses. It defines both a direct client mode, whereby a client requests a LL addresses, or block of addresses, intended for configuration on its own interface(s). Proxy client mode allows a block of addresses to be requested by a client (e.g. a hypervisor), which will then be used for configuring end-devices. One application for this function are large scale VM deployments, where the likelihood of a MAC address collision is not acceptable (due to the birthday paradox). Two new DHCPv6 options are defined for this purpose.

Working Group Summary:

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy have been raised during the authoring or review process.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Suresh Krishnan is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Awaiting Tomeck's response.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document, the result of the WGLC was determined as successful by Suresh Krishnan (responsible AD).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-slap-quadrant-04, but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of new DHCPv6 option codes for the two new DHCPv6 options that are defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document defines a new DHCPv6 based mechanism for leasing link-layer addresses to clients.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document extends the DHCPv6 protocol to include the leasing of link-layer addresses. It defines both a direct client mode, whereby a client requests a LL addresses, or block of addresses, intended for configuration on its own interface(s). Proxy client mode allows a block of addresses to be requested by a client (e.g. a hypervisor), which will then be used for configuring end-devices. One application for this function are large scale VM deployments, where the likelihood of a MAC address collision is not acceptable (due to the birthday paradox). Two new DHCPv6 options are defined for this purpose.

Working Group Summary:

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy has been raised during the authoring or review
process.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Suresh Krishnan is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Awaiting Tomeck's response.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document, the result of the WGLC was determined as successful by Suresh Krishnan (responsible AD).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-slap-quadrant-04, but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of new DHCPv6 option codes for the two new DHCPv6 options that are defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document defines a new DHCPv6 based mechanism for leasing link-layer addresses to clients.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document extends the DHCPv6 protocol to include the leasing of link-layer addresses. It defines both a direct client mode, whereby a client requests a LL addresses, or block of addresses, intended for configuration on its own interface(s). Proxy client mode allows a block of addresses to be requested by a client (e.g. a hypervisor), which will then be used for configuring end-devices. One application for this function are large scale VM deployments, where the
likelihood of a MAC address collision is not acceptable (due to the birthday paradox). Two new DHCPv6 options are defined for this purpose.

Working Group Summary:

There is consensus in the WG for the publication of this document.

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Suresh Krishnan is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Awaiting Tomeck's response.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document, the result of the WGLC was determined as successful by Suresh Krishnan (responsible AD).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-slap-quadrant-04, but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of new DHCPv6 option codes for the two new DHCPv6 options that are defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended Status: Standards Track (Indicated on title page)
This document defines a new DHCPv6 based mechanism for leasing link-layer addresses to clients.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document extends the DHCPv6 protocol to include the leasing of link-layer addresses. It defines both a direct client mode, whereby a client requests a LL addresses, or block of addresses, intended for configuration on its own interface(s). Proxy client mode allows a block of addresses to be requested by a client (e.g. a hypervisor), which will then be used for configuring end-devices. One application for this function are large scale VM deployments, where the
likelihood of a MAC address collision is not acceptable (due to the birthday paradox). Two new DHCPv6 options are defined for this purpose.

Working Group Summary:

There is consensus in the WG for the publication of this document.

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Ian Farrer is the Document Shepherd.
Suresh Krishnan is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Awaiting Tomeck's response.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus has been achieved and all of the active participants agree on the advancement of this document. As both of the DHCWG chairs are co-authors of this document, the result of the WGLC was determined as successful by Suresh Krishnan (responsible AD).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits reports an outdated informal reference to draft-ietf-dhc-slap-quadrant-04, but as the referenced document is being submitted at the same time, and it is expected that the two documents will be in the same cluster, this will be resolved in the publication process.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review are necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section requests the assignment of new DHCPv6 option codes for the two new DHCPv6 options that are defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as descibed in section 24. of RFC8415.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No registries requiring Expert Review are defined.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None (no formal language is included in the document).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG is included in the document.