DHC WG                                                     CJ. Bernardos
Internet-Draft                                                      UC3M
Intended status: Standards Track                               A. Mourad
Expires: November 28, 2020 February 4, 2021                                   InterDigital
                                                            May 27,
                                                          August 3, 2020

               SLAP quadrant selection options option for DHCPv6
                    draft-ietf-dhc-slap-quadrant-09
                    draft-ietf-dhc-slap-quadrant-10

Abstract

   The

   IEEE originally structured the 48-bit MAC address space in such a way
   that half of it was reserved for local use.  Recently, the  In 2017, IEEE
   has been working on published
   a new specification standard (IEEE Std 802c) which defines with a new optional "Structured Local
   Address Plan" (SLAP) that (SLAP).  It specifies different assignment approaches
   in four specified regions of the local MAC address space.

   The

   IEEE is working on mechanisms developing protocols to allocate assign addresses in the one of
   these quadrants (IEEE 802.1CQ). P802.1CQ).
   There is work also in the IETF on specifying a new mechanism that
   extends DHCPv6 operation to handle the local MAC address assignments.  We complement this work by
   defining a mechanism to allow choosing the SLAP quadrant to use in
   the allocation of the MAC address to the requesting device/client.

   This document proposes extensions to DHCPv6 protocols to enable a
   DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant
   to the server, so that the server allocates the may allocate MAC addresses to the
   given client out of in the
   quadrant requested by the relay or client.  A new DHCPv6 option (OPTION_SLAP_QUAD, or QUAD)
   (QUAD) is defined for this purpose.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 28, 2020. February 4, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Problem statement . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  WiFi (IEEE 802.11) devices  . . . . . . . . . . . . . . . . . . . .   4
       1.1.2.  Hypervisor: migratable vs non-migratable functions  .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6   5
   3.  Quadrant Selection Mechanisms examples  . . . . . . . . . . .   7
   4.  DHCPv6 Extensions . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.   7
     3.1.  Address Assignment from the Preferred SLAP Quadrant
           Indicated by the Client . . . . . . . . . . . . . . . . .   9
     4.2.   7
     3.2.  Address Assignment from the SLAP Quadrant Indicated by
           the Relay . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.   9
   4.  DHCPv6 Options Definitions Option Definition  . . . . . . . . . . . . . . . . .  14
     5.1. .  11
     4.1.  Quad (IA_LL) option . . . . . . . . . . . . . . . . . . .  14
   6. . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   7.  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   8.  13
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
   9.  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  17  14
   Appendix A.  Quadrant Selection Mechanisms examples . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   The

   IEEE originally structured structures the 48-bit MAC address space in such a way that half
   of it was reserved for local use (where the Universal/
   Local Universal/Local -- U/L --
   bit is set to 1).  Recently, the  In 2017, IEEE has been
   working on published a new specification standard (IEEE Std
   802c [IEEEStd802c-2017]) [IEEEStd802c]) which defines a new "optional Structured optional "Structured Local
   Address Plan" (SLAP) that specifies different assignment approaches
   in four specified regions of the local MAC address space.  These four
   regions, called SLAP quadrants, are briefly described below (see
   Figure 1 and Figure 2 for details):

   o  In SLAP Quadrant 01, "Extended Local Identifier" (ELI) MAC
      addresses are assigned based on a 24-bit Company ID (CID), which takes 24-bits, leaving
      the remaining 24-bits for the locally assigned address for each
      CID for unicast (M-bit = 0) and also for multicast (M-bit = 1).
      The CID is
      assigned by the IEEE Registration Authority (RA).  The remaining
      bits are specified as an extension by the CID assignee or by a
      protocol designated by the CID assignee.

   o  In SLAP Quadrant 11, "Standard Assigned Identifier" (SAI) MAC
      addresses are assigned based on a protocol specified in an IEEE
      802 standard.  For 48-bit MAC addresses, 44 bits are available.
      Multiple protocols for assigning SAIs may be specified in IEEE
      standards.  Coexistence of multiple protocols may be supported by
      limiting the subspace available for assignment by each protocol.

   o  In SLAP Quadrant 00, "Administratively Assigned Identifier" (AAI)
      MAC addresses are assigned locally by an administrator.  Multicast
      IPv6 packets use a destination address starting in 33-33 and this
      falls within this space and therefore 33-33, so AAI
      addresses in that range should not be used to avoid
      conflict with the MAC addresses used for use with IPv6 multicast
      addresses. assigned.  For 48-bit MAC
      addresses, 44 bits are available.

   o  SLAP Quadrant 10 is "Reserved for future use" where MAC addresses
      may be assigned using new methods yet to be defined, or until then
      by an administrator like as in the AAI quadrant.  For 48-bit MAC
      addresses, 44 bits would be available.

          LSB                MSB
          M  X  Y  Z  -  -  -  -
          |  |  |  |
          |  |  |  +------------ SLAP Z-bit
          |  |  +--------------- SLAP Y-bit
          |  +------------------ X-bit (U/L) = 1 for locally assigned
          +--------------------- M-bit (I/G) (unicast/group)

   Figure 1: IEEE 48-bit MAC address structure (in IEEE representation)

   +----------+-------+-------+-----------------------+----------------+
   | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local          |
   |          |       |       |                       | Identifier     |
   +----------+-------+-------+-----------------------+----------------+
   |    01    |   0   |   1   | Extended Local        | ELI            |
   |    11    |   1   |   1   | Standard Assigned     | SAI            |
   |    00    |   0   |   0   | Administratively      | AAI            |
   |          |       |       | Assigned              |                |
   |    10    |   1   |   0   | Reserved              | Reserved       |
   +----------+-------+-------+-----------------------+----------------+

                         Figure 2: SLAP quadrants

1.1.  Problem statement

   The

   IEEE is working on developing mechanisms to allocate assign addresses in the SAI
   quadrant (IEEE 802.1CQ project). P802.1CQ
   project) [IEEE-P802.1CQ-Project].  There is also ongoing work in the
   IETF [I-D.ietf-dhc-mac-assign] specifying a new mechanism that
   extends DHCPv6 operation to handle the local MAC address assignments.
   We complement this work by defining a mechanism to allow choosing the
   SLAP quadrant to use in the allocation of the MAC address to the
   requesting device/client.
   This document proposes extensions to DHCPv6 protocols to enable a
   DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant
   to the server, so that the server
   allocates may allocate the MAC address to the given client out of addresses in
   the quadrant requested by the relay or client.

   In the following, we describe two application scenarios where in which a
   need arises to assign local MAC addresses according to preferred SLAP
   quadrants.

1.1.1.  WiFi (IEEE 802.11) devices

   Today, most WiFi devices come with interfaces that have a "burned in"
   MAC address, allocated from the universal address space using a
   24-bit Organizationally Unique Identifier (OUI, assigned to IEEE 802
   interface vendors).  However, recently, the need to assign local
   (instead of universal) MAC addresses has emerged in particular in the
   following two scenarios:

   o  IoT (Internet of Things): where there are a lot In general, composed of cheap,
      sometimes short lived constrained
      devices [RFC7228] with constraints such as available power and
      energy, memory, and disposable devices. processing resources.  Examples of this
      include:
      include sensors and actuators for health or home automation
      applications.  In this scenario, it is common that a reasonable behavior would be
      that, upon a first boot, the device uses a temporary MAC address, address
      to send initial DHCP packets to available DHCP servers.  IoT
      devices typically
      request need a single MAC address for each available
      network interface.  Once the server assigns a MAC address, the
      device abandons its temporary MAC address.  This type of device is  Home automation IoT
      devices typically do not
      moving.  In move (however, not that there is an
      increase of smart health monitoring devices, which are mobile).
      For this type of device, in general, any type of SLAP quadrant
      would be good for assigning addresses from, addresses, but ELI/SAI quadrants might
      be more suitable in some scenarios, such as if scenarios.  For example, the addresses device might
      need to
      belong to use an address from the CID assigned to the IoT
      communication device vendor. vendor, thus preferring the ELI quadrant.

   o  Privacy: Today, MAC addresses allow the exposure of users'
      locations making it relatively easy to track users' movement. movements.
      One of the mechanisms considered to mitigate this problem is the
      use of local random MAC addresses, changing them every time the
      user connects to a different network.  In this scenario, devices
      are typically mobile.  Here, AAI is probably the best SLAP
      quadrant from which to assign addresses from, addresses, as it is the best fit for
      randomization of addresses, and it is not required for the
      addresses to survive when changing networks.

1.1.2.  Hypervisor: migratable vs non-migratable functions

   In large scale virtualization environments, thousands of virtual
   machines (VMs) are active.  These VMs are typically managed by a
   hypervisor, in charge of spawning and stopping VMs as needed.  The
   hypervisor is also typically in charge of assigning new MAC addresses
   to the VMs.  If a DHCP solution is in place for that, the hypervisor
   acts as a DHCP client and requests available DHCP servers to assign
   one or more MAC addresses (an address block).  The hypervisor does
   not use those addresses for itself, but rather uses them to create
   new VMs with appropriate MAC addresses.  If we assume very large data
   center environments, such as the ones that are typically used
   nowadays, it is expected that the data center is divided in different
   network regions, each one managing its own local address space.  In
   this scenario, there are two possible situations that need to be
   tackled:

   o  Migratable functions.  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).  Therefore, for this case, it is better
      to allocate addresses from the ELI/SAI SLAP quadrant, which can be
      centrally allocated by the DHCP server.

   o  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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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

   IA_LL         Identity Association for Link-Layer Address: an
                 identity association (IA) used to request or assign
                 link-layer addresses.  Section 10.1 of
                 [I-D.ietf-dhc-mac-assign] provides details on the IA_LL
                 option.

   LLADDR        Link-layer address option that is used to request or
                 assign a block of link-layer addresses.  Section 10.2
                 of [I-D.ietf-dhc-mac-assign] provides details on the
                 LLADDR option.

   client        A device node that is interested in obtaining link-layer
                 addresses.  It implements the basic DHCPv6 DHCP mechanisms
                 needed by a DHCPv6 DHCP client as described in [RFC8415] and
                 supports the new options (IA_LL and LLADDR) specified in [I-D.ietf-dhc-mac-assign].
                 [I-D.ietf-dhc-mac-assign], as well as the new option
                 (QUAD) specified in this document.  The client may or
                 may not support IPv6 address assignment and prefix
                 delegation as specified in [RFC8415].

   server        Software        A node that manages link-layer address allocation and
                 is able to respond to client queries.  It implements
                 basic DHCPv6 DHCP server functionality as described in
                 [RFC8415] and supports the new options (IA_LL and LLADDR)
                 specified in [I-D.ietf-dhc-mac-assign]. [I-D.ietf-dhc-mac-assign], as well as the
                 new option (QUAD) specified in this document.  The
                 server may or may not support IPv6 address assignment
                 and prefix delegation as specified in [RFC8415].

   relay         A node that acts as an intermediary to deliver DHCP
                 messages between clients and servers.  A relay, based
                 on local knowledge and policies, may include the
                 preferred SLAP quadrant in a QUAD option sent to the
                 server.  The relay implements basic DHCPv6 relay agent
                 functionality as described in [RFC8415].

   address       Unless specified otherwise, an address means a link-
                 layer (or MAC) address, as defined specified in IEEE802. IEEE Std 802
                 [IEEEStd802].  The address is typically 6 six or eight bytes long, but some network
                 architectures may use different lengths. long.

   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.

3.  DHCPv6 Extensions

3.1.  Address Assignment from the Preferred SLAP Quadrant Selection Mechanisms examples

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

   Let's take first an IoT scenario as an example.  An IoT device might
   decide on its own Client

   Next, we describe the SLAP quadrant it wants to use protocol operations for a client to obtain select a local
   MAC address,
   preferred SLAP quadrant using the following information to take DHCPv6 signaling procedures
   described in [I-D.ietf-dhc-mac-assign].  The signaling flow is shown
   in Figure 3.

    +--------+                            +--------+
    | DHCPv6 |                            | DHCPv6 |
    | client |                            | server |
    +--------+                            +--------+
        |                                      |
        +----1. Solicit(IA_LL(LLADDR,QUAD))--->|
        |                                      |
        |<--2. Advertise(IA_LL(LLADDR,QUAD))---+
        |                                      |
        +---3. Request(IA_LL(LLADDR,QUAD))---->|
        |                                      |
        |<------4. Reply(IA_LL(LLADDR))--------+
        |                                      |
        .                                      .
        .          (timer expiring)            .
        .                                      .
        |                                      |
        +---5. Renew(IA_LL(LLADDR,QUAD))------>|
        |                                      |
        |<-----6. Reply(IA_LL(LLADDR))---------+
        |                                      |

              Figure 3: DHCPv6 signaling flow (client-server)

   1.  Link-layer addresses (i.e., MAC addresses) are assigned in
       blocks.  The smallest block is a single address.  To request an
       assignment, the decision:

   o  Type of IoT deployment: e.g., industrial, domestic, rural, etc.
      For small deployments, such as domestic ones, client sends a Solicit message with an IA_LL
       option in the IoT itself can
      decide message.  The IA_LL option MUST contain a LLADDR
       option.  In order to use indicate the AAI quadrant (this might not even involve preferred SLAP quadrant(s), the
      use of DHCP, by
       IA_LL option includes the device just configuring a random address
      computed by new OPTION_SLAP_QUAD option in the device itself).
       IA_LL-option field (alongside the LLADDR option).

   2.  The server, upon receiving an IA_LL option in Solicit, inspects
       its contents.  For large deployments, such as
      industrial or rural ones, where thousands each of devices might co-
      exist, the IoT can decide entries in OPTION_SLAP_QUAD, in
       order of the preference field (highest to use lowest), the ELI or SAI quadrants.

   o  Mobility: server
       checks if the IoT device can move, then it might prefer to
      select the SAI or AAI quadrants to minimize has a configured MAC address collisions
      when moving to another network.  If pool matching the device is known to remain
      fixed, then the ELI is probably
       requested quadrant identifier, and an available range of
       addresses of the most requested size.  If suitable one to use.

   o  Managed/unmanaged: depending on whether the IoT device is managed
      during its lifetime or cannot be re-configured, the selected
      quadrant might be different.  For example, if it can be managed,
      this means that network topology changes might occur during its
      lifetime (e.g., due to changes on addresses are
       found, the deployment, such as
      extensions involving additional devices), and this might have server sends back an
      impact on Advertise message with an IA_LL
       option containing an LLADDR option that specifies the preferred quadrant (e.g., to avoid potential
      collisions in addresses
       being offered.  If the future).

   o  Operation/battery lifetime: depending on server supports the expected lifetime new QUAD IA_LL-option,
       and manages a block of
      the device addresses belonging to a different quadrant might be preferred (as before, requested
       quadrant, the addresses being offered MUST belong to
      minimize potential a requested
       quadrant.  If the server does not have a configured address collisions in pool
       matching the future).

   The previous parameters are considerations that client's request, it MUST return the device vendor/
   administrator may wish IA_LL option
       containing a Status Code option with status set to use when defining NoQuadAvail
       (IANA-2).  If the IoT device's
   MAC address request policy (i.e., how to select a given client specified more than one SLAP
   quadrant).  IoT devices are typically very resource constrained, so
   there may quadrant,
       the server MUST only be simple decision making process based on pre- return a NoQuadAvail status code if no
       address pool(s) configured preferences.

   If we now take at the WiFi device scenario, considering for example that
   a laptop or smartphone connects to a network using its built in MAC
   address.  Due to privacy/security concerns, server match any of the device might want to
   configure a local MAC address.  The device might use different
   parameters and context information to decide, not only which
       specified SLAP
   quadrant to use for quadrants.  If the local MAC address configuration, but also
   when to perform server has a change of address (e.g., it might be needed to
   change configured address several times).  This information includes,
       pool of the correct quadrant, but no available addresses, it is
   not limited to:

   o  Type of network MUST
       return the device is connected: public, work, home.

   o  Trusted network?  Y/N.

   o  First time visited network?  Y/N.

   o  Network geographical location.

   o  Mobility?  Y/N.

   o  Operating System (OS) network profile, including security/trust
      related parameters.  Most modern OSs keep metadata associated IA_LL option containing a Status Code option with
       status set to
      the networks they can attach to, as NoAddrsAvail.

   3.  The client waits for example the level available servers to send Advertise
       responses and picks one server as defined in Section 18.2.9 of trust
       [RFC8415].  The client SHOULD NOT pick a server that does not
       advertise an address in the user or administrator assigns to requested quadrant(s).  The client
       then sends a Request message that includes the network.  This
      information is used to configure how IA_LL container
       option with the device behaves LLADDR option copied from the Advertise message
       sent by the chosen server.  It includes the preferred SLAP
       quadrant(s) in terms a new QUAD IA_LL-option.

   4.  Upon reception of advertising itself on a Request message with IA_LL container option,
       the network, firewall settings, etc.  But server assigns requested addresses.  The server MAY alter the
       allocation at this information can also be used to decide whether to configure a
      local MAC time (e.g., by reducing the address or not, from which SLAP quadrant block).
       It then generates and how often.

   o  Triggers coming from applications regarding location privacy.  An
      app might request sends a Reply message back to the OS to maximize location privacy (due to client.
       Upon receiving a Reply message, the nature of client parses the application) IA_LL
       container option and this might require may start using all provided addresses.
       Note that the OS
      forces the use of a local MAC address, or client that has included a Rapid Commit option in the local MAC
      address
       Solicit, may receive a Reply in response to the Solicit and skip
       the Advertise and Request steps above (following standard DHCPv6
       procedures).

   5.  The client is changed. expected to periodically renew the link-layer
       addresses as governed by T1 and T2 timers.  This information mechanism can be used
       administratively disabled by the device to select server sending "infinity" as the
       T1 and T2 values (see Section 7.7 of [RFC8415]).  The client
       sends a Renew option after T1.  It includes the preferred SLAP
   quadrant.  For example, if
       quadrant(s) in the device is moving around (e.g., while
   connected to a public network new QUAD IA_LL-option, so in an airport), it is likely that it
   might change access point several times, and therefore it case the server
       is best unable to
   minimize extend the chances of address collision, using lifetime on the SAI or AAI
   quadrants.  If existing address(es), the device is not moving and attached to a trusted
   network (e.g. at work), then it is probably best to select the ELI
   quadrant.  These
       preferred quadrants are just some examples of how to use this
   information to select the quadrant.

   Additionally, known for the information can also be used to trigger subsequent
   changes allocation of MAC address, to enhance location privacy.  Besides,
   changing the SLAP quadrant used might also be used as any "new"
       (i.e., different) addresses.

   6.  The server responds with a Reply message, with an additional
   enhancement to make it harder to track the user location.

   Last, IA_LL option
       that includes an LLADDR option with extended lifetime.

   The client SHOULD check if we consider the data center scenario, a hypervisor might
   request local received MAC addresses to be assigned to virtual machines.  As
   in the previous scenarios, the hypervisor might select the preferred
   SLAP quadrant using information provided by the cloud management
   system (CMS) or virtualization infrastructure manager (VIM) running
   on top address comes from one of
   the hypervisor.  This information might include, but is not
   limited to:

   o  Migratable VM.  If the function implemented by the VM is subject
      to be moved to another physical server or not.  This has an impact
      on the preference for requested quadrants.  It MAY repeat the SLAP quadrant, as some quadrants are
      better suited (e.g., ELI/SAI) for supporting migration in a large
      data center.

   o  VM connectivity characteristics , e.g.,: standalone, part of a
      pool, part of process selecting a service graph/chain.  If the connectivity
      characteristics of the VM are known, this can be used by the
      hypervisor to select the best SLAP quadrant.

4.  DHCPv6 Extensions

4.1.
   different DHCP server.

3.2.  Address Assignment from the Preferred SLAP Quadrant Indicated by the Client Relay

   Next, we describe the protocol operations for a client relay to select a
   preferred SLAP quadrant using the DHCPv6 signaling procedures
   described in [I-D.ietf-dhc-mac-assign].  This is useful when a DHCPv6
   server is operating over a large infrastructure split in different
   network regions, where each region might have different requirements.
   The signaling flow is shown in Figure 3. 4.

   +--------+                  +--------+                     +--------+
   | DHCPv6 |                  | DHCPv6 |                     | DHCPv6 |
   | client |                  | relay  |                     | server |
   +--------+                  +--------+                     +--------+
      |                            |
        +-------1. Solicit(IA_LL(QUAD))------->|                                |
      +-----1. Solicit(IA_LL)----->|                                |
        |<--2. Advertise(IA_LL(LLADDR,QUAD))--+|
      |                            +----2. Relay-forward            |
      |
        +---3. Request(IA_LL(LLADDR,QUAD))---->|                            |    (Solicit(IA_LL),QUAD)------>|
      |                            |                                |
      |                            |<---3. Relay-reply              |
      |                            |    (Advertise(IA_LL(LLADDR)))--+
      |<4. Advertise(IA_LL(LLADDR))+                                |
      |-5. Request(IA_LL(LLADDR))->|                                |
      |                            +-6. Relay-forward               |
      |                            | (Request(IA_LL(LLADDR)),QUAD)->|
      |                            |                                |
      |                            |<--7. Relay-reply               |
      |                            |   (Reply(IA_LL(LLADDR)))-------+
      |<--8. Reply(IA_LL(LLADDR))--+                                |
        |<------4. Reply(IA_LL(LLADDR))--------+
      |                            |                                |
      .                            .                                .
      .                    (timer expiring)                         .
      .                            .                                .
      |                            |
        +---5. Renew(IA_LL(LLADDR,QUAD))------>|                                |
      +--9. Renew(IA_LL(LLADDR))-->|                                |
      |                            |--10. Relay-forward             |
      |                            |  (Renew(IA_LL(LLADDR)),QUAD)-->|
      |                            |                                |
      |                            |<---11. Relay-reply             |
      |                            |     (Reply(IA_LL(LLADDR)))-----+
      |<--12. Reply(IA_LL(LLADDR)--+                                |
      |
        |<-----6. Reply(IA_LL(LLADDR))---------+                            |                                |

           Figure 3: 4: DHCPv6 signaling flow (client-server) (client-relay-server)

   1.   Link-layer addresses (i.e., MAC addresses) are assigned in
        blocks.  The smallest block is a single address.  To request an
        assignment, the client sends a Solicit message with an IA_LL
        option in the message.  The IA_LL option MUST contain a LLADDR
        option.  In order to indicate

   2.   The DHCP relay receives the preferred SLAP quadrant(s), Solicit message and encapsulates it
        in a Relay-forward message.  The relay, based on local knowledge
        and policies, includes in the
       IA_LL Relay-forward message the QUAD
        option includes with the new OPTION_SLAP_QUAD preferred quadrant.  The relay might know which
        quadrant to request based on local configuration (e.g., the
        served network contains IoT devices only, thus requiring ELI/
        SAI) or other means.  Note that if a client sends multiple
        instances of the IA_LL option in the
       IA_LL-option field (with same message, the LLAADR option).

   2.  The server, upon DHCP
        relay MAY only add a single instance of the QUAD option.

   3.   Upon receiving a relayed message containing an IA_LL option, the
        server inspects its
       contents.  For each of the entries in OPTION_SLAP_QUAD, in order contents for instances of OPTION_SLAP_QUAD
        in both the preference field (highest to lowest), Relay Forward message and the server checks if
       it has a client's message
        payload.  Depending on the server's policy, the instance of the
        option to process is selected (see also at the end of this
        section).  For each of the entries in OPTION_SLAP_QUAD, in order
        of the preference field (highest to lowest), the server checks
        if it has a configured MAC address pool matching the requested
        quadrant identifier, and an available range of addresses of the
        requested size.  If suitable addresses are found, the server
        sends back an Advertise message with an IA_LL option containing
        an LLADDR option that specifies the addresses being offered.
        This message is sent to the Relay in a Relay-reply message.  If
        the server supports the new semantics of the preferred quadrant
        included in the QUAD IA_LL-option, option, and manages a block of addresses
        belonging to the a requested quadrant(s), quadrant, then the addresses being
        offered MUST belong to the a requested quadrant(s).
       If the quadrant.  The server does not have a configured address pool matching SHOULD
        apply the client's request, it MUST return contents of the IA_LL option containing
       a Status Code relay's supplied QUAD option with status set to NoQuadAvail (IANA-2).  If
       the client specified more than one SLAP quadrant, the server MUST
       only return a NoQuadAvail status code if no address pool(s)
       configured at the server match any for all
        of the specified SLAP
       quadrants.  If the server has a client's IA_LLs, unless configured address pool of the
       correct quadrant, but no available addresses, it MUST return to do otherwise.

   4.   The relay sends the
       IA_LL option containing a Status Code option with status set received Advertise message to
       NoAddrsAvail.

   3. the client.

   5.   The client waits for available servers to send Advertise
        responses and picks one server as defined in Section 18.2.9 of
        [RFC8415].  The client SHOULD NOT pick a server that does not
       advertise an address in the requested quadrant.  The client then sends a Request message that
        includes the IA_LL container option with the LLADDR option
        copied from the Advertise message sent by the chosen server.  It includes

   6.   The relay forwards the preferred SLAP quadrant(s) received Request in a Relay-forward
        message.  It adds in the new Relay-forward a QUAD IA_LL-option.

   4. IA_LL-option with
        the preferred quadrant.

   7.   Upon reception of a the forwarded Request message with IA_LL
        container option, the server assigns requested addresses.  The
        server MAY alter the allocation at this time.  It then generates
        and sends a Reply
       message message, in a Relay-reply back to the client. relay.

   8.   Upon receiving a Reply message, the client parses the IA_LL
        container option and may start using all provided addresses.  Note that a client that has included a Rapid
       Commit option in the Solicit, may receive a Reply in response to
       the Solicit and skip the Advertise and Request steps above
       (following standard DHCPv6 procedures).

   5.  The

   9.   The client is expected to periodically renew the link-layer
        addresses as governed by T1 and T2 timers.  This mechanism can
        be administratively disabled by the server sending "infinity" as
        the T1 and T2 values (see Section 7.7 of [RFC8415]).  When the
       assigned addresses are about to expire, the  The client
        sends a Renew
       message.  It includes option after T1.

   10.  This message is forwarded by the preferred SLAP quadrant(s) relay in the new a Relay-forward
        message, including a QUAD IA_LL-option, so in case the server is unable to extend the
       lifetime on the existing address(es), IA_LL-option with the preferred quadrants are
       known for the allocation of any "new" (i.e., different)
       addresses.

   6.
        quadrant.

   11.  The server responds with a Reply message, including an LLADDR
        option with extended lifetime.  This message is sent in a Relay-
        reply message.

   12.  The client relay sends the Reply message back to the client.

   The server SHOULD check if implement a configuration parameter to deal
   with the received MAC address comes from one case where the client's DHCP message contains an instance of
   OPTION_SLAP_QUAD, and the requested quadrants.  Otherwise, relay adds a second instance in its relay-
   forward message.  This parameter configures the client SHOULD NOT configure server to process
   either the obtained address. client's, or the relay's instance of option QUAD.  It MAY repeat is
   RECOMMENDED that the process selecting default for such a
   different DHCP server.

4.2.  Address Assignment from parameter is to process the SLAP Quadrant Indicated by
   client's instance of the Relay

   Next, we describe option.

   The client MAY check if the protocol operations for a relay received MAC address belongs to select a
   preferred SLAP
   quadrant using it is willing to use/configure, and MAY decide based on that
   whether to use configure the received address.

4.  DHCPv6 signaling procedures
   described in [I-D.ietf-dhc-mac-assign].  This Option Definition

4.1.  Quad option

   The QUAD option is useful when a DHCPv6
   server is operating over a large infrastructure split in different
   network regions, where each region might have different requirements. used to specify the preferences for the selected
   quadrants within an IA_LL.  The signaling flow is shown option MUST either be encapsulated in Figure 4.

   +--------+                  +--------+                     +--------+
   | DHCPv6 |                  | DHCPv6 |                     | DHCPv6 |
   | client |                  | relay  |                     | server |
   +--------+                  +--------+                     +--------+
      |                            |                                |
      +-----1. Solicit(IA_LL)----->|                                |
      |                            +----2. Relay-forward            |
      |                            |    (Solicit(IA_LL),QUAD)------>|
      |                            |                                |
      |                            |<---3. Relay-reply              |
      |                            |    (Advertise(IA_LL(LLADDR)))--+
      |<4. Advertise(IA_LL(LLADDR))+                                |
      |-5. Request(IA_LL(LLADDR))->|                                |
      |                            +-6.
   the IA_LL-options field of an IA_LL option or in a Relay-forward
   message.

   The format of the QUAD option is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OPTION_SLAP_QUAD        |          option-len           | (Request(IA_LL(LLADDR)),QUAD)->|
      |                            |                                |
      |                            |<--7. Relay-reply               |
      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   (Reply(IA_LL(LLADDR)))-------+
      |<--8. Reply(IA_LL(LLADDR))--+   quadrant-1  |    pref-1     |   quadrant-2  |    pref-2     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                                                               .                    (timer expiring)                         .
      .                            .                                .
      |                            |                                |
      +--9. Renew(IA_LL(LLADDR))-->|                                |
      |                            |--10. Relay-forward             |
      |                            |  (Renew(IA_LL(LLADDR)),QUAD)-->|
      |                            |                                |
      |                            |<---11. Relay-reply             |
      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     (Reply(IA_LL(LLADDR)))-----+
      |<--12. Reply(IA_LL(LLADDR)--+  quadrant-n-1 |   pref-n-1    |   quadrant-n  |    pref-n     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 4: DHCPv6 signaling flow (client-relay-server)

   1.   Link-layer addresses (i.e., MAC addresses) are assigned in
        blocks.  The smallest block is a single address.  To request an
        assignment, 5: Quad Option Format

   option-code     OPTION_SLAP_QUAD (IANA-1).

   option-len      2 * number of included (quadrant, preference).  A
                   2-byte field containing the client sends a Solicit message with an IA_LL
        option total length of all
                   (quadrant, preference) pairs included in the message.  The IA_LL option MUST contain a LLADDR option.

   2.   The DHCP relay receives

   quadrant-n      Identifier of the Solicit message and encapsulates it
        in a Relay-forward message.  The relay, based on local knowledge
        and policies, includes quadrant (0: AAI, 1: ELI, 2:
                   Reserved by IEEE [IEEEStd802c], 3: SAI).  Each
                   quadrant MUST only appear once at most in the Relay-forward message the QUAD
        option with the option.
                   A 1-byte field.

   pref-n          Preference associated to quadrant-n.  A higher value
                   means a more preferred quadrant.  The relay might know which  A 1-byte field.

   A quadrant to request based on local configuration (e.g., the
        served network contains IoT devices only, thus requiring ELI/
        SAI) or other means.  Note that if a client sends multiple
        instances of the IA_LL option in the same message, the DHCP
        relay identifier value MUST only add a single instance of appear at most once in the QUAD
   option.

   3.   Upon receiving a relayed message containing If an IA_LL option, the
        server inspects the contents for instances option includes more than one occurrence of OPTION_SLAP_QUAD
        in both the Relay Forward message and same
   quadrant identifier, only the client's message
        payload.  Depending on first occurence is processed and the server's policy,
   rest MUST be ignored by the instance(s) of server.

   If the option to process same preference value is selected.  For each of used for more than one quadrant, the entries in
        OPTION_SLAP_QUAD, in order
   server MAY select which quadrant should be preferred (if the server
   can assign addresses from all or some of the preference field (highest to
        lowest), quadrants with the server checks if it has a configured MAC address
        pool matching the requested quadrant identifier, and an
        available range same
   assigned preference).  Note that this is not a simple list of addresses
   quadrants ordered by preference without no preference value but a
   list of quadrants with explicit preference values.  This way it can
   support the requested size. case whereby a client really has no preference between
   two or three quadrants, leaving the decision to the server.

   If suitable
        addresses are found, the client or relay agent provide the OPTION_SLAP_QUAD, the server sends back an Advertise message
        with an IA_LL option containing an LLADDR option that specifies
   MUST use the addresses being offered.  This message is sent quadrant-n/pref-n values to order the Relay
        in a Relay-reply message. selection of the
   quadrants.  If the server supports the semantics can provide an assignment from one of the preferred quadrant included in
   specified quadrants, it SHOULD proceed with the QUAD option, and
        manages assignment.  If the
   server does not have a block configured address pool matching any of addresses belonging to the requested
        quadrant(s), then the addresses being offered
   specified quadrant-n fields, it MUST belong to NOT assign any addresses and
   return a status of NoQuadAvail (IANA-2) in the
        requested quadrant(s).  The server SHOULD apply IA_LL Option.  If the contents
   server has a configured address pool of the relay's supplied QUAD correct quadrant, but no
   available addresses, it MUST return the IA_LL option for all containing a
   statis of NoAddrsAvail.

   There is no requirement that the client's IA_LLs,
        unless configured to do otherwise.

   4.   The client or relay sends the received Advertise message to agent order the client.

   5.   The client waits for available servers to send Advertise
        responses and picks one server as defined
   quadrant/pref values in Section 18.2.9 of
        [RFC8415].  The client then sends a Request message any specific order; hence servers MUST NOT
   assume that
        includes quadrant-1/pref-1 have the IA_LL container option with highest preference (except if
   there is only 1 set of values).

5.  IANA Considerations

   IANA is requested to assign the LLADDR QUAD (IANA-1) option
        copied code from the Advertise message sent by the chosen server.

   6.   The relay forwards the received Request in a Relay-forward
        message.  It adds in the Relay-forward a QUAD IA_LL-option with
        the preferred quadrant.

   7.   Upon reception of
   DHCPv6 "Option Codes" registry maintained at
   http://www.iana.org/assignments/dhcpv6-parameters and use the forwarded Request message with IA_LL
        container option,
   following data when adding the server assigns requested addresses.  The
        server MAY alter option to the allocation at registry:

       Value: IANA-1
       Description: OPTION_SLAP_QUAD
       Client ORO: No
       Singleton Option: No
       Reference: this time.  It then generates
        and sends a Reply message, in a Relay-reply back document

   IANA is requested to assign the relay.

   8.   Upon receiving a Reply message, NoQuadAvail (IANA-2) code from the client parses
   DHCPv6 "Status Codes" registry maintained
   athttp://www.iana.org/assignments/dhcpv6-parameters and use the
   following data when adding the IA_LL
        container option and may start using all provided addresses.

   9.   The client is expected to periodically renew the link-layer
        addresses as governed by T1 registry:

       Value: IANA-2
       Description: NoQuadAvail
       Reference: this document

6.  Security Considerations

   See [RFC8415] and T2 timers.  This mechanism can
        be administratively disabled by the server sending "infinity" as [RFC7227] for the T1 DHCPv6 security and T2 values (see Section 7.7 of [RFC8415]).  When the
        assigned addresses are about to expire, the client sends a Renew
        message.

   10.  This message is forwarded by privacy
   considerations.  See [RFC8200] for the Relay in a Relay-forward
        message, including a QUAD IA_LL-option with the preferred
        quadrant.

   11.  The server responds with a Reply message, including an LLADDR
        option with extended lifetime.  This message is sent in a Relay-
        reply message.

   12. IPv6 security considerations.

   See also [I-D.ietf-dhc-mac-assign] for security considerations
   regarding link-layer address assignments using DHCP.

7.  Acknowledgments

   The relay sends the Reply message back authors would like to the client.

   The server SHOULD implement a configuration parameter thank Bernie Volz for his very valuable
   comments on this document.  We also want to deal
   with the case where the client's DHCP message contains an instance of
   OPTION_SLAP_QUAD, thank Ian Farrer, Tomek
   Mrugalski, Eric Vyncke, Tatuya Jinmei, Carl Wallace, Ines Robles, Ted
   Lemon, Jaime Jimenez, Robert Wilton, Benjamin Kaduk, Barry Leiba,
   Alvaro Retana and the relay adds a second instance in its relay-
   forward message.  This parameter configures the server to process
   either the client's, or the relay's instance of option QUAD.  It is
   RECOMMENDED that the default Murray Kucherawy for such a parameter is to process the
   client's instance of the option.

   The client MAY check if the received MAC address belongs to a
   quadrant it is willing their very detailed and
   helpful reviews.  And to use/configure, Roger Marks and MAY decide based on that
   whether Antonio de la Oliva for
   comments related to use configure the received address.

5.  DHCPv6 Options Definitions

5.1.  Quad (IA_LL) option IEEE work and references.

   The QUAD option is used to specify work in document draft has been supported by the preferences H2020 5Growth
   (Grant 856709) and 5G-DIVE projects (Grant 859881).

8.  References

8.1.  Normative References

   [I-D.ietf-dhc-mac-assign]
              Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer
              Addresses Assignment Mechanism for the selected
   quadrants within an IA_LL.  The option MUST either be encapsulated DHCPv6", draft-ietf-
              dhc-mac-assign-08 (work in
   the IA_LL-options field progress), July 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of an IA_LL option or Uppercase vs Lowercase in a Relay-forward
   message.

   The format RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.

8.2.  Informative References

   [IEEE-P802.1CQ-Project]
              IEEE, "IEEE P802.1CQ: Multicast and Local Address
              Assignment".

   [IEEEStd802]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks: Overview and Architecture, IEEE Std 802-2014",
              June 2014.

   [IEEEStd802c]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks: Overview and Architecture, Amendment 2: Local
              Medium Access Control (MAC) Address Usage, IEEE Std 802c-
              2017", June 2017.

   [RFC7227]  Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
              S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
              BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
              <https://www.rfc-editor.org/info/rfc7227>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7548]  Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A.
              Sehgal, "Management of the QUAD option is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Networks with Constrained Devices:
              Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015,
              <https://www.rfc-editor.org/info/rfc7548>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OPTION_SLAP_QUAD        |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   quadrant-1  |    pref-1     |   quadrant-2  |    pref-2     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 5: Quad Option Format

   option-code     OPTION_SLAP_QUAD (IANA-1).

   option-len      2 * number
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

Appendix A.  Quadrant Selection Mechanisms examples

   This appendix describes some examples of how the quadrant preference
   mechanisms could be used.

   Let's take first an IoT scenario as an example.  An IoT device might
   decide on its own the SLAP quadrant it wants to use to obtain a local
   MAC address, using the following information to take the decision:

   o  Type of included (quadrant, preference).  A
                   2-byte field containing IoT deployment: e.g., industrial, domestic, rural, etc.
      For small deployments, such as domestic ones, the total length IoT device
      itself can decide to use the AAI quadrant (this might not even
      involve the use of all
                   (quadrant, preference) pairs included in DHCP, by the option.

   quadrant-n      Identifier device just configuring a random
      address computed by the device itself).  For large deployments,
      such as industrial or rural ones, where thousands of devices might
      co-exist, the quadrant (0: AAI, 1: ELI, 2:
                   Reserved, 3: SAI).  Each quadrant MUST only appear
                   once at most in IoT can decide to use the option.  A 1-byte field.

   pref-n          Preference associated ELI or SAI quadrants.

   o  Mobility: if the IoT device can move, then it might prefer to quadrant-n.  A higher value
                   means a
      select the SAI or AAI quadrants to minimize address collisions
      when moving to another network.  If the device is known to remain
      fixed, then the ELI is probably the most suitable one to use.

   o  Managed/unmanaged: depending on whether the IoT device is managed
      during its lifetime or cannot be re-configured [RFC7548], the
      decision of what quadrant is more appropriate might be different.
      For example, if the IoT device can be managed (e.g., configured),
      and network topology changes might occur during its lifetime
      (e.g., due to changes on the deployment, such as extensions
      involving additional devices), this has an impact on the preferred quadrant.  A 1-byte field.

   A
      quadrant identifier value MUST only appear at most once (e.g., to avoid potential collisions in the
   option. If an option includes more than one occurrence future).

   o  Operation/battery lifetime: depending on the expected lifetime of
      the same device a different quadrant identifier, only might be preferred (as before, to
      minimize potential address collisions in the first occurence is processed and future).

   The previous parameters are considerations that the
   rest MUST be ignored by device vendor/
   administrator may wish to use when defining the server.

   If IoT device's
   MAC address request policy (i.e., how to select a given SLAP
   quadrant).  IoT devices are typically very resource constrained, so
   there may only be a simple decision-making process based on pre-
   configured preferences.

   We now take the same preference value is used WiFi device scenario, considering for more than one quadrant, example that a
   laptop or smartphone connects to a network using its built in MAC
   address.  Due to privacy/security concerns, the
   server MAY select device might want to
   configure a local MAC address.  The device might use different
   parameters and context information to decide, not only which SLAP
   quadrant should to use for the local MAC address configuration, but also
   when to perform a change of address (e.g., it might be preferred (if needed to
   change address several times).  This information includes, but it is
   not limited to:

   o  Type of network the server device is connected: public, work, home.

   o  Trusted network: Yes/No.

   o  First time visited network: Yes/No.

   o  Network geographical location.

   o  Mobility: Yes (the device might change its network attachment
      point)/No (the device is not going to change its network
      attachment point).

   o  Operating System (OS) network profile, including security/trust
      related parameters: most modern OSs keep metadata associated to
      the networks they can assign addresses from all or some attach to, as for example the level of trust
      the quadrants with user or administrator assigns to the same
   assigned preference).  Note that a quadrant - preference tuple network.  This
      information is used to configure how the device behaves in this option (instead of using a list terms
      of quadrants ordered by
   preference) to support advertising itself on the case whereby network, firewall settings, etc.  But
      this information can also be used to decide whether to configure a client really has no
   preference between two
      local MAC address or three quadrants, leaving not, from which SLAP quadrant and how often.

   o  Triggers coming from applications regarding location privacy.  An
      app might request to the decision OS to maximize location privacy (due to
      the server.

   If nature of the client or relay agent provide application) and this might require that the OPTION_SLAP_QUAD, OS
      forces the server
   MUST use the quadrant-n/pref-n values to order the selection of a local MAC address, or that the
   quadrants.  If the server local MAC
      address is changed.

   This information can provide an assignment from one of the
   specified quadrants, it SHOULD proceed with be used by the assignment.  If device to select the
   server cannot provide an assignment from one of SLAP
   quadrant.  For example, if the specified
   quadrant-n fields, it MUST NOT assign any addresses and return device is moving around (e.g., while
   connected to a
   status of NoQuadAvail (IANA-2) public network in the IA_LL Option.

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

6.  IANA Considerations

   IANA it
   might change access point several times, and therefore it is requested best to assign
   minimize the QUAD (IANA-1) option code from chances of address collision, using the
   DHCPv6 "Option Codes" registry maintained at
   http://www.iana.org/assignments/dhcpv6-parameters SAI or AAI
   quadrants.  If the device is not expected to move and attached to a
   trusted network (e.g. in some scenarios at work), then it is probably
   best to select the ELI quadrant.  These are just some examples of how
   to use this information to select the
   following data when adding quadrant.

   Additionally, the option information can also be used to the registry:

       Value: IANA-1
       Description: OPTION_SLAP_QUAD
       Client ORO: No
       Singleton Option: No
       Reference: this document

   IANA is requested trigger subsequent
   changes of MAC address, to assign enhance location privacy.  Besides,
   changing the NoQuadAvail (IANA-2) code from SLAP quadrant might also be used as an additional
   enhancement to make it harder to track the
   DHCPv6 "Status Codes" registry maintained
   athttp://www.iana.org/assignments/dhcpv6-parameters and use user location.

   Last, if we consider the
   following data when adding the option center scenario, a hypervisor might
   request local MAC addresses to be assigned to virtual machines.  As
   in the registry:

       Value: IANA-2
       Description: NoQuadAvail
       Reference: this document

7.  Security Considerations

   See [RFC8415] for previous scenarios, the DHCPv6 security considerations.  See [RFC8200]
   for hypervisor might select the IPv6 security considerations.

   See also [I-D.ietf-dhc-mac-assign] for security considerations
   regarding link-layer address assignments preferred
   SLAP quadrant using DHCP.

8.  Acknowledgments

   The authors would like information provided by the cloud management
   system or virtualization infrastructure manager running on top of the
   hypervisor.  This information might include, but is not limited to:

   o  Migratable VM.  If the function implemented by the VM is subject
      to thank Bernie Volz for his very valuable
   comments on this document.  We also want be moved to thank Ian Farrer, Tomek
   Mrugalski, Eric Vyncke, Tatuya Jinmei and Carl Wallace another physical server or not.  This has an impact
      on the preference for their very
   detailed and helpful reviews.

   The work in this draft will be further developed and explored under the framework of SLAP quadrant, as the H2020 5Growth (Grant 856709) and 5G-DIVE
   projects (Grant 859881).

9.  References

9.1.  Normative References

   [I-D.ietf-dhc-mac-assign]
              Volz, B., Mrugalski, T., ELI and C. Bernardos, "Link-Layer
              Addresses Assignment Mechanism for DHCPv6", draft-ietf-
              dhc-mac-assign-06 (work in progress), May 2020.

   [RFC2119]  Bradner, S., "Key words SAI
      quadrants are better suited for use supporting migration in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity a large
      data center.

   o  VM connectivity characteristics , e.g., standalone, part of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.

9.2.  Informative References

   [IEEEStd802c-2017]
              IEEE Computer Society, "IEEE Standard for Local and
              Metropolitan Area Networks: Overview and Architecture,
              Amendment 2: Local Medium Access Control (MAC) Address
              Usage, IEEE Std 802c-2017". a
      pool, part of a service graph/chain.  If the connectivity
      characteristics of the VM are known, this can be used by the
      hypervisor to select the best SLAP quadrant.

Authors' Addresses
   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc/

   Alain Mourad
   InterDigital Europe

   Email: Alain.Mourad@InterDigital.com
   URI:   http://www.InterDigital.com/