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

From: [email-masked]
Date: Tue, 7 Jan 2020 14:46:03 +0100

Hi,

I’ll be shepherding both of these documents. Please see the following comments
on draft-ietf-dhc-mac-assign-01. I’ll provide comments on draft-ietf-dhc-slap-quadrant-01
in a separate mail.

Thanks,
Ian

General point - The document doesn't place any requirements on how a client
creates its DUID. Could this result in having multiple clients with the same DUID?
Clients with clashes in the default/initial MAC address using e.g. DUID-Type 3
(which would have to be based on the initial MAC and
remain constant for the duration of the lease), isn't there the potential
for DUID conflict?

---------

1. Introduction
"Another use case is IoT devices.  Typically there is no need to  provide global
uniqueness of MAC addresses for such devices.  On the  other hand, the huge
number of such devices would likely exhaust a  vendor's OUI (Organizationally
Unique Identifier) global address space."

It's not clear to me how this supports the need for the DHCP based allocation
of MAC addresses as the first point seems to override the relevance of the
second. Based on what I think it’s trying to say, here’s an updated text proposal:

"Another use case is IoT devices.  The huge number of such devices would
likely exhaust a vendor's OUI (Organizationally Unique Identifier) global address
space, and while there is typically no need to provide global uniqueness for
such devices, a link-layer assingment mechanisms allows for conflicts
to be avoided inside an administrative domain."

-----------

7. Requesting Addresses
"The client MUST be able to handle a response that contains an address
 or addresses different than those requested."

Suggest that the following is used to include another of the described deviation cases:

"The client MUST be able to handle a response containing a smaller number of addresses,
or an address or addresses different than those requested."

The above suggestion is also relevant for the paragraph related to the Relpy message
later in the section.

-----------

10.2 Link-Layer Addresses Option
link-layer-type  - it would be useful if this provided a reference to the relevant
IANA table at 
https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-2

========================

> On 30. Oct 2019, at 02:51, Tomek Mrugalski <[email-masked]> wrote:
> 
> Hi,
> This mail initiates a Working Group Last Call on two related IDs:
> 
> Link-Layer Addresses Assignment Mechanism for DHCPv6
> draft-ietf-dhc-mac-assign-01
> https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01
> 
> and
> 
> SLAP quadrant selection options for DHCPv6
> draft-ietf-dhc-slap-quadrant-01
> https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-01
> 
> Authors believe those drafts are ready for WGLC. Please post your
> substantial comments and your opinion whether those are ready for
> publication or not. If you have minor editorial comments, you may send
> them to the authors directly.
> 
> Please post your comments by Nov. 17th.
> 
> Cheers,
> Tomek
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: [email-masked]
Date: Tue, 7 Jan 2020 16:10:37 +0100

Hi,

As mentioned in my previous email, here is my review of draft-ietf-dhc-slap-quadrant-01.

Thanks,
Ian

Major Comments
———————————

Section 4.2

If the relay needs to insert the Quad option, then as I understand it, the right way to do this would be for the relay to put it into a Relay Supplied Option Option
(RSOO RFC6422). This requires an update to the IANA table at:

https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option
-----

Step 3. If the client is sending multiple instances of the IA_LL, how are these associated to the relevant Quad option(s) added
by the relay, or is only a single quadrant possible for all of the IA_LLs in the client’s message?
------

Section 5.1

The structure of the option seems needlessly complex and introduces problems/exceptions that currently aren’t discussed, but could be 
avoided. i.e. what happens if a quadrant id appears more than once? What if two id’s have the same preference values?

Couldn’t a simple, ordered list be used here? This would be processed in order (first to last) until a match is found. RFC8026 provides
an example of this.
———

I’m not sure if a new IANA registry of the valid values for the 'quadrant-n’ field is necessary. I’d appreciate the Chairs input on this.
--------

Sections 6 and 7.

The IANA and Security Considerations need to be completed. I’ve indicated necessary registry updates where relevant.

Minor Comments
-----------------------

Section 3.

"Migratable/non-migratable VM.  If the function implemented by the VM is subject to be moved
to another physical server or not.”

Is the above statement accurate? Surely it’s the migration of the VM (and its function) to a new
physical server that matters here.
———

Section 4.1

A ’NoQuadAvail’ error code is mentioned, but this is the only place in the document it occurs. If a new
DHCPv6 error code is being created, then this needs to be defined and the IANA registry updated:
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-5

———
Section 5.1
The ERO option is introduced here, but I’m not sure how/why this would be used. If the server was to echo a Quad option back
to a relay, what does it do with the received information?

Grammar / Wording comments
-----------------------------------------

1.1.1. Wifi Devices
"but ELI/SAI quadrants might be more suitable in some scenarios,
such as if it is needed that the addresses belong to the CID
assigned to the IoT communication device vendor.”

Wording is quite cumbersome, suggest:

"but ELI/SAI quadrants might be more suitable in some scenarios,
such as if the addresses need to belong to the CID assigned to the IoT communication
 device vendor.”
——

1.1.2 Hypervisor: migratable vs non-migratable functions

If a VM (providing a given function) might  need to be potentially migrated
to another region of the data center (due to maintenance, resilience,
end-user mobility, etc.) it is needed that this VM can keep its
networking context in the new region, and this includes keeping
its MAC addresses.

The language is a bit redundnat in this sentance. Suggested re-word:

If a VM (providing a given function) needs to be migrated to another region
of the data center (e.g. for maintenance, resilience, end-user mobility, etc.),
the VM's networking context needs to migrate with the VM. This includes the VM's
MAC address(es).
---

Non-migratable functions.  If a VM will not be migrated to another
      region of the data center, there are no requirements associated to
      its MAC address, and then it is more efficient to allocate it from
      the AAI SLAP quadrant, which does not need to be same for all the
      data centers (i.e., each region can manage its own, without
      checking for duplicates globally).

Suggested re-word for readability:

Non-migratable functions.  If a VM will not be migrated to another
      region of the data center, there are no requirements associated with
      its MAC address. In this case, it is more efficient to allocate it from
      the AAI SLAP quadrant, that does not need to be unique across
     multiple data centers (i.e., each region can manage its own MAC address
     assignment, without checking for duplicates globally).
——————

2. Terminology

This has the following sentence:
"The DHCPv6 terminology relevant to this specification from the DHCPv6
   Protocol [RFC8415] applies here.”

…then goes on to redefine client and server. Suggest that the above sentence
is replaced with:

“Where relevant, the DHCPv6 terminology from the DHCPv6
Protocol [RFC8415] also applies here. Additionally, the following definitions are updated
for this document."
----

There also needs to be a definition for the relay function, as it needs to be updated for
the Quad option as well.
—————

3. Quadrant selection mechanisms

s/Quadrant selection mechanisms/Quadrant Selection Mechanisms/
----

"We next describe some exemplary ways to perform SLAP quadrant
   selection.  These are provided just as informational text to
   exemplify how the quadrant preference mechanisms could be used.”

Suggested re-word:

The following section describes some examples of how the quadrant preference mechanisms could be used.
——

Putting the IoT, Wifi and Data Center examples into their own sub-sections would improve the structure and 
readability.
———

The way that the IoT’s SLAP quadrant decision making is written implies a level of autonomy and free will
that devices don’t possess and many of considerations are unknowable to the device itself. The bullet points are
considerations that the device vendor/administrator may wish to use when defining the IoT device’s MAC 
address request policy. Please reword to reflect this.
——

"IoT devices are typically very
   resource constrained, so it might be as well that simple decisions
   are just taken, for example based on pre-configured preferences.”

Suggested reword for clarity:

"IoT devices are typically very
   resource constrained, so there may only be simple decision making
process based on pre-configured preferences.”
——

s/Most modern OS/Most modern OSs/
——

s/and this might mean the OS to force the use or change of a local MAC address./
and this might require that the OS forces the use of a local MAC address, or that
the local MAC address is changed./
———

4.1 Address assignment from the preferred SLAP quadrant indicated by
      the client

s/Address assignment from the preferred SLAP quadrant indicated by
      the client/Address Assignment from the Preferred SLAP Quadrant Indicated by
      the Client/
——

s/We describe next/Next, we describe/
----

Much of the content of this section duplicates what is described in [I-D.ietf-dhc-mac-assign].
It would be better just to have a pointer to the relevant sections of that document and describe
the changes that the Quad option makes to this process.
————

4.2 Address assignment from the SLAP quadrant indicated by the relay

s/Address assignment from the SLAP quadrant indicated by the relay/Address Assignment from the SLAP Quadrant Indicated by the Relay/
——

s/We describe next/Next, we describe/
——

Figure 4 seem to show that the relay adds the Quad option into the client's SOLICIT - i.e. alters the contents of the client’s
message.

This is not described by the body text, but the diagram needs to be fixed to avoid confusion here.
———

5.1. DHCPv6 options definitions

s/DHCPv6 options definitions/DHCPv6 Option Definition/
——

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Tue, 7 Jan 2020 18:06:28 +0100

Dear Ian,

Thanks a lot for your very detailed review. I'll follow up on that on the
mailing list and publish a new version (once we have agreed on all the
changes) in the next few days.

Carlos

On Tue, Jan 7, 2020 at 4:11 PM <[email-masked]> wrote:

> If the relay needs to insert the Quad option, then as I understand it,
> the right way to do this would be for the relay to put it into a Relay
> Supplied Option Option
> Step 3. If the client is sending multiple instances of the IA_LL, how are
> these associated to the relevant Quad option(s) added
> The structure of the option seems needlessly complex and introduces
> problems/exceptions that currently aren’t discussed, but could be
> avoided. i.e. what happens if a quadrant id appears more than once? What
> if two id’s have the same preference values?
>
> Couldn’t a simple, ordered list be used here? This would be processed in
> order (first to last) until a match is found. RFC8026 provides
> an example of this.
> ———
>
> I’m not sure if a new IANA registry of the valid values for the 'quadrant-n’
> field is necessary. I’d appreciate the Chairs input on this.
> --------
>
>
> Sections 6 and 7.
>
>
> The IANA and Security Considerations need to be completed. I’ve indicated
> necessary registry updates where relevant.
>
>
>
> Minor Comments
> -----------------------
>
> Section 3.
>
> The ERO option is introduced here, but I’m not sure how/why this would be
> used. If the server was to echo a Quad option back
> s/Address assignment from the SLAP quadrant indicated by the relay/Address
> Assignment from the SLAP Quadrant Indicated by the Relay/
> ——
>
> Figure 4 seem to show that the relay adds the Quad option into the
> client's SOLICIT - i.e. alters the contents of the client’s
> message.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 7 Jan 2020 17:54:28 +0000

Hi:

Suresh has reviewed the WGLC and determined that this document has passed the last-call.

As an author, I will shortly publish the updated version and then Ian, as shepherd, will go the write-up to send it on to the IESG.

As neither Tomek nor I are authors of the slap-quadrant document, Suresh has asked us to make the WGLC determination. We will do that over the next few days.

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of Bernie Volz (volz)
Sent: Tuesday, December 3, 2019 12:07 PM
To: Tomek Mrugalski <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] WGLC comments on draft-ietf-dhc-mac-assign-01

Hi Tomek:

Some comments on your comments inline below (prefixed by BV>).

I have updated the github repository, but not published an 02 just yet. So, the fixed comments refer to the coming 02 (see the github repository version).

I'll wait a bit to see if you (or anyone else) have any comments regarding this email before publishing the 02 revision.

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of Tomek Mrugalski
Sent: Sunday, November 17, 2019 2:48 PM
To: [email-masked]
Subject: [dhcwg] WGLC comments on draft-ietf-dhc-mac-assign-01

Disclaimer: I used to be involved in the draft-ietf-dhc-mac-assign a year ago. I asked the other authors to remove my name from it, but they feel my contributions were significant enough to keep it on.

So it's with my co-chair and co-author hats off, I support this work moving forward. However, I have some comments that should be addressed.

Nitpicks:
Section 6, bullet numbering is wrong (no item 2) Section 6, bullet 3: block of address => block of addresses

BV> Fixed. An earlier version had added ability to request multicast addresses, but that was removed and the bullet numbers were not adjusted (as with XML2RFC V2, we must manually maintain numbered lists).

Section 6 properly explains that the client is supposed to set the valid lifetime field to 0. I'd like to see a text for the other side: the server MUST ignore the valid lifetime value.

BV> OK, the text there said that the server should ignore but I adjusted it to use MUST. Later text also documented that the server MUST ignore:

   In a message sent by a client to a server, the valid lifetime field
   SHOULD be set to 0.  The server MUST ignore any received value.

Nitpick: "a IA_LL" => "an IA_LL". RFC8415 uses an for all IA options.

BV> Fixed.

"The server MAY alter the allocation at this time." This is technically incorrect. Server doesn't have any allocation yet, it's about to make one. Better text would be: "The server allocates block of addresses according to its configured policy. The server MAY assign a different block than requested in the Request message."

BV> Fixed.

Text in section 10.2: "This value can be only sent by a client that requests a new block.". There are two issues with this text. First, I would rephrase this text. The sentence as written now suggests that the only entity allowed to set this field is a client and only under certain circumstances. Maybe something like this: "A client is only allowed to set this value when requesting a new block?". The second problem with this text is that it's not really true, is it? What about renewals?
Client is expected to send the block it already has for renewal.

BV> Fixed. Used " link-layer address that is being requested or renewed, or  a special value to request any address."

"extra-addresses - A four octets long field". Would be useful to clarify that it's an unsigned field encoded in network byte order.

BV> Fixed - add RFC8415 text in all of the placed where integers are used in options.

End of section 10.2: "More than one LLADDR option can appear in an IA_LL option." This seems to be in contradiction with earlier text that says "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.". So what are the circumstances when more than one LLADDR is present in IA_LL? If there are none, perhaps best would be to remove this sentence?

BV> I'm not sure why a "can" contradicts a SHOULD. Just because the usual case would be a single LLADDR (i.e., SHOULD), I don't see why we would need to prohibit having more than one LLADDR (i.e., can). And, we don't really know the use cases someone may have in the future, so I would prefer not to restrict this.  I can see two ways forward - leave as is (perhaps use "MAY" instead of "can") or remove both statements.

BV> Note that SHOULD is:
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

BV> And MAY is:
5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

BV> I think the bottom line (just as with IAPREFIX/IAADDR options in IA_PD/IA_NA), a server MUST be able to support multiple instances of these options within a single IA.

Section 13 should probably mentioned that there is no duplicate detection mechanism such as DAD for IPv6. It's not really a problem, though. A malicious node can start using any MAC address and doesn't have to go through the hassles of implementing this protocol.

BV> Hum ... doesn't the paragraph that is there already explain this?

   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.

I hope to review the second draft in the coming days. Will send a separate mail.

BV> Any comments on the slap-quadrant draft would be appreciated.

Thanks,
Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 7 Jan 2020 21:05:49 +0000

In addition to Ian’s comments, I will add the following for you and the WG to consider:

For section 5.1, pref-n, I’d suggest explain what this value means (is a lower value more “preferred” or a higher?).

I’m also still wondering whether a simpler mechanism would just be to have the client provide the list of quadrant values it would like in the order of preference, so the option would be just quadrant-1, quadrant-2, […]. I’m really not sure what the pref value adds and it makes things more complicated in processing.

If you do keep the quad/pref, you should make it clear whether there is any requirement in terms of ordering or not (I would guess you would want not).

And, in either case, what does the absence of a quadrant mean – that the server SHOULD NOT assign this or assume they are of even lower preference? This is buried in the text section 4.1, item #2:

                                              If the server does not
       have addresses from the requested quadrant, it MUST return the
       IA_LL option containing a Status Code option with status set to
       NoQuadAvail.

I think you would want to specify the processing rules in the option description (i.e., section 5.1).

And, the text earlier in sections 4.1 and 4.2 says “In order to indicate the preferred SLAP quadrant,“ but that seems to be indicating only 1 – not a list of possible values?

Perhaps in 5.1, after the fields, you should add something like:

If the client or relay agent provide the OPTION_QUAD, the server uses the quadrant-n/pref-n values to order the selection of the quadrants. If the server can provide an assignment from one the specified quadrants, it should proceed with the assignment. If the server cannot provide an assignment from one of the specified quadrant-n fields, it MUST NOT assign any addresses and return a status of NoQuadAvail in the IA_LL Option.

There is no requirement that the client or relay agent order the quadrant/pref values in any specific order; hence servers MUST NOT assume that quadrant-1/pref-1 have the highest preference (except if there is only 1 set of values).

Client and relay agent MUST NOT place the same quadrant value into the option more than once; however servers should be capable of dealing with this by using the more preferred instance (as it requires no special handling).

If the same preference value is used for more than one quadrant, the behavior as to which is more preferred is random.

But also note that servers that do not support the OPTION_QUAD will proceed with assigning from whatever may be available. So, I’m wondering if this behavior is really the best – does the client (or relay agent) need to check that the addresses were assigned from the quadrant?

Since this and the mac-assign document should probably go as a package, perhaps this argues for requiring implementation of both? Or perhaps we should have the server that supports and used the OPTION_QUAD echo it back (in the IA_LL-options field for clients and Relay-Reply for relay agent) as that would be one way for the client or relay agent to know the server understood it (this would also remove the need for this to be support in the ERO option). Also, if the relay agent’s value was used (overrides the clients), it would NOT be echoed back in the IA_LL-option – just in the Relay-Reply)?

As a nit, you probably should be consistent in usage of Relay-Forw and Relay-Reply (some cases lower case is used) … and per RFC8415, the usage is:
                Relay-forward and Reply-reply when referring to the messages
                RELAY-FORW and RELAY-REPLY when referring to the msg-type of a message
So, you want to use “Relay-forward” and “Reply-reply” in pretty much all cases?

  *   Bernie

From: dhcwg <[email-masked]> On Behalf Of CARLOS JESUS BERNARDOS CANO
Sent: Tuesday, January 7, 2020 12:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

Dear Ian,

Thanks a lot for your very detailed review. I'll follow up on that on the mailing list and publish a new version (once we have agreed on all the changes) in the next few days.

Carlos

On Tue, Jan 7, 2020 at 4:11 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks,
Ian

Major Comments
———————————

Section 4.2

https://www..iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option<https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option>
-----

Section 5.1

Sections 6 and 7.

Minor Comments
-----------------------

Section 3.

Is the above statement accurate? Surely it’s the migration of the VM (and its function) to a new
physical server that matters here..
———

Section 4.1

———
Section 5.1

1.1.1. Wifi Devices

2. Terminology

Suggested re-word:

On 30. Oct 2019, at 02:51, Tomek Mrugalski <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Link-Layer Addresses Assignment Mechanism for DHCPv6
draft-ietf-dhc-mac-assign-01
https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01<https://tools.ietf..org/html/draft-ietf-dhc-mac-assign-01>

and

Cheers,
Tomek

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: [email-masked]
Date: Wed, 8 Jan 2020 17:50:59 +0100

Hi Bernie / Carlos,

The following paragraph in Bernie’s comments raises a couple of questions:

"Since this and the mac-assign document should probably go as a package, perhaps this argues for requiring implementation of both? Or perhaps we should have the server that supports and used the OPTION_QUAD echo it back (in the IA_LL-options field for clients and Relay-Reply for relay agent) as that would be one way for the client or relay agent to know the server understood it (this would also remove the need for this to be support in the ERO option). Also, if the relay agent’s value was used (overrides the clients), it would NOT be echoed back in the IA_LL-option – just in the Relay-Reply)?”

1, I’m not clear what a relay agent can do by knowing whether the server implements OPTION_QUAD or not.

If the relay is configured to add OPTION_QUAD to the relay-forward message. The contents of this is based on its (static) configuration. If the server understands it and has the correct address type available, it allocates it and sends to the relay. The relay sends the IA_LL to the client.

If the server doesn’t understand it, OPTION_QUAD is ignored, an allocation is made based on whatever the server is configured with and this gets relayed to the client. The relay doesn’t look at the contents of the IA_LL.

What useful action can the relay take based on knowing that the server doesn’t implement OPTION_QUAD?

2, The question of priority in the case that a client sends OPTION_QUAD in its IA_LL and the relay also adds OPTION_QUAD is also interesting. I can see cases where you would want the relay's option to be used over the client’s. But, in the case of a mixed environment where there are devices without OPTION_QUAD and varied types of devices that do (mobile devices, IoT, MAC address randomization for privacy etc.), you may want the server to take the client’s OPTION_QUAD (if present) over the relay’s. It would be worth having some discussion of this is the document.

Thanks,
Ian

> On 7. Jan 2020, at 22:05, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Bernie
> On Tue, Jan 7, 2020 at 4:11 PM <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
>  
> https://www..iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option <https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option>
> -----
>  
> https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-5 <https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-5>
>  
> ———
> Section 5.1
> On 30. Oct 2019, at 02:51, Tomek Mrugalski <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
> https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01 <https://tools.ietf..org/html/draft-ietf-dhc-mac-assign-01>
> 
> and
> 
> https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-01 <https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-01>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Jan 2020 17:05:20 +0000

Hi:

Regarding (1), that probably is a good question. And, as the relay and server are more “controlled” (usually in the same administrative domain), perhaps it is not a consideration – other than it may be something to point out?

Regarding (2), I would think that if the relay provided the option, it was an administratively configured choice and so should override the client (i.e., it is administrative policy). I guess we could make it configurable on the server which is to be preferred (though we’d still need to recommend a default)?

But it does get tricky with what do you tell the client in terms of what happened with its preferences (and what if the relay and client preferences match)?

Let’s see what the slap-quadrant authors want to suggest for how to address these issues?

  *   Bernie
From: [email-masked] <[email-masked]>
Sent: Wednesday, January 8, 2020 11:51 AM
To: Bernie Volz (volz) <[email-masked]>; CARLOS JESUS BERNARDOS CANO <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

Hi Bernie / Carlos,

Thanks,
Ian

On 7. Jan 2020, at 22:05, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

                                              If the server does not

  *   Bernie

From: dhcwg <[email-masked]<mailto:[email-masked]>> On Behalf Of CARLOS JESUS BERNARDOS CANO
Sent: Tuesday, January 7, 2020 12:06 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

Dear Ian,

Carlos

Thanks,
Ian

Major Comments
———————————

Section 4.2

Section 5.1

Sections 6 and 7.

Minor Comments
-----------------------

Section 3.

Section 4.1

———
Section 5.1

1.1.1. Wifi Devices

2. Terminology

Suggested re-word:

Hi,

and

Cheers,
Tomek

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 13 Jan 2020 14:46:44 +0100

Dear Ian,

Thanks again for the very helpful and detailed review I've updated the
document according to your comments (-02).

Please find below my initial responses to your comments.

> of draft-ietf-dhc-slap-quadrant-01.

[CB] As I understand RFC6422, this is useful if the relay needs to provide
info to the client, but this is not the case. We just need the relay to
include the preference to be considered by the server when assigning the
link-local address.

> by the relay, or is only a single quadrant possible for all of the IA_LLs

[CB] We assumed that only a single Quad option could be sent, applying
those preferences to all IA_LLs in the client message. I've added some text
explicitly explaining this (in Steps 2 and 3).

> order (first to last) until a match is found. RFC8026 provides

[CB] Since not all the quadrants might appear in the option, we believe
it's better to keep the current format, but we agree that we have to add
text to discuss how different cases should be addressed, and which ones
should be avoided. I've added some text to clarify that part.

> field is necessary. I’d appreciate the Chairs input on this.

[CB] I'll wait for Chairs' advise on this.

> necessary registry updates where relevant.

[CB] Thanks, I've completed both sections.

> Minor Comments

[CB] OK, I've removed the "non-migratable" part to make it more
clear/accurate.

> https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-5

[CB] I've added it to the IANA considerations sections.

> to a relay, what does it do with the received information?

[CB] I've removed it, because we don't really need this.

> Grammar / Wording comments

[CB] Thanks, I've adopted your suggested text.

> the VM's networking context needs to migrate with the VM. This includes

[CB] Thanks, I've adopted your suggested text.

>      assignment, without checking for duplicates globally).

[CB] Thanks, I've adopted your suggested text.

> Protocol [RFC8415] also applies here. Additionally, the following

[CB] Thanks, I've adopted your suggested text.

> There also needs to be a definition for the relay function, as it needs to

[CB] I've added it. Thanks.

> s/Quadrant selection mechanisms/Quadrant Selection Mechanisms/

[CB] Done, thanks.

> preference mechanisms could be used.

[CB] Done, thanks.

> would improve the structure and

[CB] I have mixed feelings here. I see your point, but I still like the
distinction between WiFi devices (that includes both IoT and WiFi devices
required additional privacy protection) and the data center (hypervisors).
I'll think a bit more about it. If others have an opinion on this, that
would be appreciated.

———
> address request policy. Please reword to reflect this.

[CB] Done.

> process based on pre-configured preferences.”

[CB] Done.

> s/Most modern OS/Most modern OSs/

[CB] Done.

——
> the local MAC address is changed./

[CB] Done.

>       the client/Address Assignment from the Preferred SLAP Quadrant

[CB] Done.

> s/We describe next/Next, we describe/

[CB] Done.

> the changes that the Quad option makes to this process.

[CB] I prefer to keep it is for completion. I'd like to hear other opinions
as well.

> Assignment from the SLAP Quadrant Indicated by the Relay/

[CB] Done.

> s/We describe next/Next, we describe/

[CB] Done.

> This is not described by the body text, but the diagram needs to be fixed

[CB] I'm not sure I follow this. The next says that "The relay, based on
local knowledge and policies, includes in the Relay-Forw message the QUAD
option with the preferred quadrant.", so it is described in the text, or am
I missing something?

———
> s/DHCPv6 options definitions/DHCPv6 Option Definition/

[CB] Done.

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 13 Jan 2020 14:46:56 +0100

Hi Bernie,

Thanks a lot for the comments. I've updated the doc according to your
comments (-02).

Please see inline below some feedback from my side.

On Tue, Jan 7, 2020 at 10:05 PM Bernie Volz (volz) <[email-masked]> wrote:

> For section 5.1, pref-n, I’d suggest explain what this value means (is a
> lower value more “preferred” or a higher?).
>

[CB] I've added some text explaining that higher means more "preferred".

>
>
> I’m also still wondering whether a simpler mechanism would just be to have
> the client provide the list of quadrant values it would like in the order
> of preference, so the option would be just quadrant-1, quadrant-2, […]. I’m
> really not sure what the pref value adds and it makes things more
> complicated in processing.
>

>
> If you do keep the quad/pref, you should make it clear whether there is
> any requirement in terms of ordering or not (I would guess you would want
> not).
>

[CB] Following Ian's comment I've tried to explain better how to process
this. I still believe it's good to have the option as is, but we can
discuss about it and change it if needed.

>
>
> And, in either case, what does the absence of a quadrant mean – that the
> server SHOULD NOT assign this or assume they are of even lower preference?
> This is buried in the text section 4.1, item #2:
>
>
>
>                                               If the server does not
>

[CB] Good point, done.

>
>
> And, the text earlier in sections 4.1 and 4.2 says “In order to indicate
> the preferred SLAP quadrant,“ but that seems to be indicating only 1 –
> not a list of possible values?
>

[CB] Fixed.

> If the client or relay agent provide the OPTION_QUAD, the server uses the
> quadrant-n/pref-n values to order the selection of the quadrants. If the
> server can provide an assignment from one the specified quadrants, it
> should proceed with the assignment. If the server cannot provide an
> assignment from one of the specified quadrant-n fields, it MUST NOT assign
> any addresses and return a status of NoQuadAvail in the IA_LL Option.
>
>
>
> There is no requirement that the client or relay agent order the
> quadrant/pref values in any specific order; hence servers MUST NOT assume
> that quadrant-1/pref-1 have the highest preference (except if there is only
> 1 set of values).
>
>
>
> Client and relay agent MUST NOT place the same quadrant value into the
> option more than once; however servers should be capable of dealing with
> this by using the more preferred instance (as it requires no special
> handling).
>
>
>
> If the same preference value is used for more than one quadrant, the
> behavior as to which is more preferred is random.
>

[CB] Thanks a lot Bernie! I had drafted some similar text to address your
and Ian's comments, but your text is better.

>
>
> But also note that servers that do not support the OPTION_QUAD will
> proceed with assigning from whatever may be available. So, I’m wondering if
> this behavior is really the best – does the client (or relay agent) need to
> check that the addresses were assigned from the quadrant?
>

[CB] I think we don't need to specify this. The requester can always check
if the assigned address belongs to the most preferred quadrant and take any
action (if needed).

>
>
> Since this and the mac-assign document should probably go as a package,
> perhaps this argues for requiring implementation of both? Or perhaps we
> should have the server that supports and used the OPTION_QUAD echo it back
> (in the IA_LL-options field for clients and Relay-Reply for relay agent) as
> that would be one way for the client or relay agent to know the server
> understood it (this would also remove the need for this to be support in
> the ERO option). Also, if the relay agent’s value was used (overrides the
> clients), it would NOT be echoed back in the IA_LL-option – just in the
> Relay-Reply)?
>

[CB] To be honest, I think I could use a bit of advice here. I removed the
ERO part (as hinted by Ian) and I'm not sure which implementation option is
best to recommend.

>
>
>
>
> As a nit, you probably should be consistent in usage of Relay-Forw and
> Relay-Reply (some cases lower case is used) … and per RFC8415, the usage is:
>
[CB] I think I fixed this. I'm using "Relay-forward" "Relay-reply".

Thanks a lot!

Carlos

>
>
>    - Bernie
>
>
>
> *From:* dhcwg <[email-masked]> *On Behalf Of * CARLOS JESUS
> BERNARDOS CANO
> *Sent:* Tuesday, January 7, 2020 12:06 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and
> draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17
>
>
>
> Dear Ian,
>
>
>
> If the relay needs to insert the Quad option, then as I understand it, the
> right way to do this would be for the relay to put it into a Relay Supplied
> Option Option
>
> https://www..iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option
> <https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option>
>
> -----
>
>
>
> <https://tools.ietf..org/html/draft-ietf-dhc-mac-assign-01>
>
> and
>

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 13 Jan 2020 14:47:00 +0100

Hi,

Nice and interesting discussion. Please see below some inline comments from
my side.

On Wed, Jan 8, 2020 at 6:05 PM Bernie Volz (volz) <[email-masked]> wrote:

> Hi:
>
>
>
> Regarding (1), that probably is a good question. And, as the relay and
> server are more “controlled” (usually in the same administrative domain),
> perhaps it is not a consideration – other than it may be something to point
> out?
>
>
>
[CB] I agree with Bernie.

> Regarding (2), I would think that if the relay provided the option, it was
> an administratively configured choice and so should override the client
> (i.e., it is administrative policy). I guess we could make it configurable
> on the server which is to be preferred (though we’d still need to recommend
> a default)?
>
>
>
> But it does get tricky with what do you tell the client in terms of what
> happened with its preferences (and what if the relay and client preferences
> match)?
>
>
[CB] I also agree here with Bernie. I think the relay should be able to
override the client, but it makes sense to be able to configure that
behavior on the server, recommending as default that the relay preferences
overrides the client's. I've added some text to address this in -02. Please
let me know what you think of it.

Thanks!

Carlos

> *From:* [email-masked] <[email-masked]>
> *Sent:* Wednesday, January 8, 2020 11:51 AM
> *To:* Bernie Volz (volz) <[email-masked]>; CARLOS JESUS BERNARDOS CANO <
> [email-masked]>
> *Cc:* [email-masked]
> "Since this and the mac-assign document should probably go as a package,
> Relay-Reply)?”
> If the relay is configured to add OPTION_QUAD to the relay-forward
> message. The contents of this is based on its (static) configuration. If
> the server understands it and has the correct address type available, it
> allocates it and sends to the relay. The relay sends the IA_LL to the
> client.
>
>
>
> If the server doesn’t understand it, OPTION_QUAD is ignored, an allocation
> is made based on whatever the server is configured with and this gets
> relayed to the client. The relay doesn’t look at the contents of the IA_LL.
>
>
>
> 2, The question of priority in the case that a client sends OPTION_QUAD in
> its IA_LL and the relay also adds OPTION_QUAD is also interesting. I can
> see cases where you would want the relay's option to be used over the
> client’s. But, in the case of a mixed environment where there are devices
> without OPTION_QUAD and varied types of devices that do (mobile devices,
> IoT, MAC address randomization for privacy etc.), you may want the server
> to take the client’s OPTION_QUAD (if present) over the relay’s. It would be
> worth having some discussion of this is the document.
>
>
>
>
>
> Thanks,
>
> Ian
>
>
>
>
>
>
>
> *From:* dhcwg <[email-masked]> *On Behalf Of *CARLOS JESUS
> BERNARDOS CANO
> I’m not sure if a new IANA registry of the valid values for the
> 'quadrant-n’ field is necessary. I’d appreciate the Chairs input on this.
>
> --------
>
>
>
>
>
> Sections 6 and 7.
>
>
>
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 13 Jan 2020 22:57:50 +0000

Thanks for the update.

Here’s a few comments on the updated (02) version:

I am still struggling with the value of the preference field. I still think an ordered list, in the preference order, would be far simpler. There really is nothing that the preference provides, except for the ordering. Removing the preference value reduces the complexity; and again, doesn’t seem to have any added value.

In section 4.2, #2:

        message from the client.  Note that if the client is sending

        multiple instances of the IA_LL in the same message, the DHCP

        relay MUST include a single QUAD option, that applies to all of

        the IA_LLs in the client's message.

Perhaps “the DHCP relay MUST ONLY include a single QUAD option”. I think the ONLY part is what is important here?

Also, later in the paragraph at the end of the section, fix “QUAD_REALY_PREF” (QUAD_RELAY_PREF).

In section 5.1:

In the quadrant-n description you have:

                                           If an option includes more
                   than one occurence of the same quadrant, only the
                   first occurence is processed and the rest MUST be
                   ignored by the server.

But later in the text which follows:

   Client and relay agent MUST NOT place the same quadrant value into

   the option more than once; however servers should be capable of

   dealing with this by using the more preferred instance (as it

   requires no special handling).

Which is it?

I’d also suggest for the field definitions to keeping to a description of what it is and the data type – use the text after the field definitions to define the rules for how the data is processed. That is the model we used in RFC8415.

And, you might fix:

   If the server can provide an assignment from one the specified

   quadrants, it should proceed with the assignment

One of the specified quadrants?

For the IANA section, you should define the full details for the new option (the options have Client ORO and Singleton Option columns in the table and you need to tell IANA what to put here – No for both). IANA calls the “error codes” Status Codes. I actually need to fix the mac-assign document to address the additional columns for the 2 options requested there. You may want to see https://tools.ietf.org/html/draft-ietf-dhc-dhcp4o6-saddr-opt-08#section-10 for how this was handled in a recent RFC’s draft.

Minor: Should OS be defined somewhere to be operating system, or is that too obvious? There are only 4 usages in Section 3, so perhaps change first to define it?

  *   Bernie

From: dhcwg <[email-masked]<mailto:[email-masked]>> On Behalf Of CARLOS JESUS BERNARDOS CANO
Sent: Monday, January 13, 2020 8:47 AM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

Hi Bernie,

Thanks a lot for the comments. I've updated the doc according to your comments (-02).

On Tue, Jan 7, 2020 at 10:05 PM Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
In addition to Ian’s comments, I will add the following for you and the WG to consider:

[CB] Following Ian's comment I've tried to explain better how to process this. I still believe it's good to have the option as is, but we can discuss about it and change it if needed.

                                              If the server does not
       NoQuadAvail..

[CB] Good point, done.

[CB] Fixed.

[CB] Thanks a lot Bernie! I had drafted some similar text to address your and Ian's comments, but your text is better.

[CB] I think we don't need to specify this. The requester can always check if the assigned address belongs to the most preferred quadrant and take any action (if needed).

[CB] To be honest, I think I could use a bit of advice here. I removed the ERO part (as hinted by Ian) and I'm not sure which implementation option is best to recommend.

Thanks a lot!

Carlos

---

From: [email-masked]
Date: Tue, 14 Jan 2020 12:22:56 +0100

Hi Carlos,

Thanks for the update. I’ve got a few more comments on the current version, in addition to Bernie's.

Thanks and best regards,
Ian 

Overall:
Could I propose changing the option name to ‘OPTION_SLAP_QUAD’, as OPTION_QUAD is quite ambiguous, especially out of context?

Section 4.1 Step 2:

"If the server supports the new QUAD IA-LL-option, and manages
a block of addresses belonging to the requested quadrant, the
addresses being offered SHOULD belong to the requested
quadrant.  If the server does not have addresses from the
requested quadrant, it MUST return the IA_LL option
containing a Status Code option with status set to NoQuadAvail (IANA-2).”

1, This should describe the process of checking the QUAD option’s 
priorities to find the highest priority quadrant with an available address.

2, What is the case where a server has addresses available from a requested
quadrant, but makes an allocation from a different quadrant (i.e. why is this a SHOULD,
not a MUST)?

3, For the NoQuadAvail error, am I right in saying that there are two cases that could be
generated:
i, The server does not have a configured address pool matching the client’s request.
ii, The server has a configured address pool of the correct quadrant, but no available 
addresses.

Really, these are not the same error. (i) is a NoQuadAvail, but (ii) is more like the
existing Code 2 NoAddrsAvail. Would this be a better choice to use here?

4,  Is NoQuadAvail sent for every higher QUAD preference that can’t
be met? i.e. if the client specifies ELI, SAI, AAI in that order, but the server can only
supply AAI, then does it send NoQuadAvail for ELI and SLI? My guess is that it shouldn’t,
but the current text could be read to mean that.

5, It would be better throughout this paragraph to use ‘a requested quadrant’ instead of
’the requested quadrant’ as the document is describing a mechanism for indicating
the preference of multiple quadrant types.

---

Section 4.1 Step3. 
1, Does the client perform any validation that the received MAC address comes from one of 
the requested quadrants? If the address doesn’t, what does the client do? I think it would be worth having
some text on how the client is expected to behave in this case. This is especially important
in the case of the relay adding the option, as if the quadrant the relay prefers is one that the
client will not configure, then there’s a risk of breaking things.

----

Section 4.2 Step 3.

"or other means such as based on analyzing the Solicit message from the client."

I’m a little uncomfortable about this line as to implement this requires additional logic in
the relay. IME experience this does not tend to go very well
(see draft-fkhp-dhc-dhcpv6-pd-relay-requirements). If this logic is necessary, then I think
it’s behaviour needs to be properly specified. If not, I would rather see this line removed.
It could always be specified in a follow up document if necessary.

---

Section 5.1
1, For the quadrant-n description, the values 3 & 4 are listed as reserved. As this is a mapping of
 a 2-bits (Y-bit and Z-bit), why are there a total of 5 values (0-4 incl.) listed?
Also, as the table in Fig 2 already effectively gives values for each of the types, wouldn’t it 

2, There’s a discrepancy in the new text between:

"If a same preference value is used for more than one quadrant,
it is left to the server implementation which
quadrant should be preferred (if the server can
assign addresses from all of some of the quadrants
with the same assigned preference).”

and

I suggest that the second paragraph is deleted as the first offers more flexibility for implementors. 
However, if the option format is changed to an ordered list, then this is no longer necessary.

———

One other grammatical nits on rereading:

4. s/DHCPv6 extensions/DHCPv6 Extensions/

In addition, please see the following comments on your answers. I’ve removed the ones that are closed.

> https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option <https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option>
> 
> [CB] As I understand RFC6422, this is useful if the relay needs to provide info to the client, but this is not the case. We just need the relay to include the preference to be considered by the server when assigning the link-local address.

[if - On re-reading RFC6422, I agree.]

> [CB] We assumed that only a single Quad option could be sent, applying those preferences to all IA_LLs in the client message. I've added some text explicitly explaining this (in Steps 2 and 3).

[if - Isn’t there a requirement on the server as well as the relay here? The relay only adds one instance of QUAD, but the server has the requirement on how this is to be interpreted. How about the following text for both step 2 & 3 (I’ve incorporated Bernie’s text suggestion as well)?:

old:
Note that if the client is sending  multiple instances of the IA_LL
in the same message, the DHCP relay MUST include a single
QUAD option, that applies to all of the IA_LLs in the client's message.

new:
Note that if a client sends multiple instances of the IA_LL
option in the same message, the DHCP relay MUST ONLY add a single
instance of the QUAD option. The server SHOULD apply the
contents of the relay’s supplied QUAD option for all of the
client’s IA_LLs, unless configured to do otherwise.

> [CB] Since not all the quadrants might appear in the option, we believe it's better to keep the current format, but we agree that we have to add text to discuss how different cases should be addressed, and which ones should be avoided. I've added some text to clarify that part.

[if - I’m with Bernie on this. It would be much simpler. Using an ordered list format does not mean that every value has to appear in it. ]

> [CB] I'll wait for Chairs' advise on this.

[if - I wonder if a point

> [CB] I've added it to the IANA considerations sections.

[if - As Bernie notes, the IANA section still needs some work.]

> [CB] I've added it. Thanks.

[if - One question about the wording here - does the relay need to support IA_LL, or only QUAD? I don’t see
any requirement for the relay to look for instances of IA_LL in the client’s messages, and the relay doesn’t 
create them itself.)

> [CB] I have mixed feelings here. I see your point, but I still like the distinction between WiFi devices (that includes both IoT and WiFi devices required additional privacy protection) and the data center (hypervisors). I'll think a bit more about it. If others have an opinion on this, that would be appreciated.
> 
> ———
> 

[if - OK]

> [CB] I prefer to keep it is for completion. I'd like to hear other opinions as well.

[if - OK]

> [CB] I'm not sure I follow this. The next says that "The relay, based on local knowledge and policies, includes in the Relay-Forw message the QUAD option with the preferred quadrant.", so it is described in the text, or am I missing something?

[if - I should have explained this better. Figure 4 shows the following:

2. Relay-forward
(Solicit(IA_LL),QUAD)

The parentheses seem to indicate that QUAD is being inserted either into the client’s solicit message, or the relay_msg). The following format shows the encapsulations better:

Relay-forward
((RELAY_MSG(SOLICIT(IA_LL)),QUAD))
]

>> https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01 <https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01>
>> 
>> and
>>