• In SLAP Quadrant 01, Extended Local Identifier (ELI) MAC addresses areassigned based on a 24-bit Company ID (CID), which is assigned by the IEEE RegistrationAuthority (RA). The remaining bits are specified as an extension by the CIDassignee or by a protocol designated by the CID assignee.
• In SLAP Quadrant 11, Standard Assigned Identifier (SAI) MAC addresses areassigned based on a protocol specified in an IEEE 802 standard. For 48-bit MACaddresses, 44 bits are available. Multiple protocols for assigning SAIs may bespecified in IEEE standards. Coexistence of multiple protocols may be supportedby limiting the subspace available for assignment by each protocol.
• In SLAP Quadrant 00, Administratively Assigned Identifier (AAI) MAC addressesare assigned locally by an administrator. Multicast IPv6 packets use adestination address starting in 33-33, so AAI addresses in that range should notbe assigned. For 48-bit MAC addresses, 44 bits are available.
• SLAP Quadrant 10 is "Reserved for future use" where MAC addresses may beassigned using new methods yet to be defined or until then by an administratoras 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)

       Legend:
       LSB: Least Significant Bit
       MSB: Most Significant Bit
       

• IoT (Internet of Things): In general, composed of constrained devices [RFC 7228] with constraints such as available powerand energy, memory, and processing resources. Examples of this include sensors and actuators forhealth or home automation applications. Given the increasingly high number ofthese devices, manufacturers might prefer to equip devices with temporary MACaddresses used only at first boot. These temporary MAC addresses would just beused to send initial DHCP packets to available DHCP servers. IoT devicestypically need a single MAC address for each available network interface. Oncethe server assigns a MAC address, the device would abandon its temporary MACaddress. Home automation IoT devices typically do not move (however, note thatthere is an increase of mobile smart health monitoring devices). Forthis type of device, in general, any type of SLAP quadrant would be good forassigning addresses, but ELI/SAI quadrants might be more suitable in somescenarios. For example, the device might need to use an address from the CIDassigned to the IoT communication device vendor, thus preferring the ELIquadrant.
• Privacy: Today, MAC addresses allow the exposure of user locations making itrelatively easy to track user movements. One of the mechanisms considered tomitigate this problem is the use of local random MAC addresses: changing themevery time the user connects to a different network. In this scenario, devicesare typically mobile. Here, AAI is probably the best SLAP quadrant from which toassign addresses; it is the best fit for randomization of addresses, and it isnot required for the addresses to survive when changing networks.

• 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). Since the assignments from the ELI/SAI SLAP quadrants are governed by rules per IEEE Std 802c, they are more appropriate for use to ensure MAC address uniqueness globally in the data center.
• Functions that are not migratable: 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 simpler to allocate it from the AAI SLAP quadrant, which 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).

address

Unless specified otherwise, a link-layer (or MAC) address, as specified in [IEEEStd802]. The address is 6 or 8 bytes 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.

client

A node that is interested in obtaining link-layer addresses. It implements the basic DHCP mechanisms needed by a DHCP client, as described in [RFC 8415], and supports the options (IA_LL and LLADDR) specified in [RFC 8947] 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 [RFC 8415].

IA_LL

Identity Association for Link-Layer Address, an identity association (IA) used to request or assign link-layer addresses. Section 11.1 of RFC 8947 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 11.2 of RFC 8947 provides details on the LLADDR option.

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 [RFC 8415].

server

A node that manages link-layer address allocation and is able to respond to client queries. It implements basic DHCP server functionality, as described in [RFC 8415], and supports the options (IA_LL and LLADDR) specified in [RFC 8947] 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 [RFC 8415].

 +--------+                            +--------+
 | 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))---------+
     |                                      |

1. Link-layer addresses (i.e., MAC addresses) are assigned in blocks. The smallestblock is a single address. To request an assignment, the client sends a Solicitmessage with an IA_LL option in the message. The IA_LL option MUST contain anLLADDR option. In order to indicate the preferred SLAP quadrant(s), the IA_LLoption includes the new OPTION_SLAP_QUAD option in the IA_LL-option field (alongside theLLADDR option).
2. The server, upon receiving an IA_LL option in a Solicit message, inspects its contents.For each of the entries in the OPTION_SLAP_QUAD, in order of the preference field(highest to lowest), the server checks if it has a configured MAC address poolmatching the requested quadrant identifier and an available range of addressesof the requested size. If suitable addresses are found, the server sends back anAdvertise message with an IA_LL option containing an LLADDR option thatspecifies the addresses being offered. If the server manages a block ofaddresses belonging to a requested quadrant, the addresses being offered MUSTbelong to a requested quadrant. If the server does not have a configured addresspool matching the client's request, it SHOULD return the IA_LL option with theaddresses being offered belonging to a quadrant managed by the server (followinga local policy to select from which of the available quadrants). If the serverhas a configured address pool of the correct quadrant but no availableaddresses, it MUST return the IA_LL option containing a Status Code option withstatus set to NoAddrsAvail.
3. The client waits for available servers to send Advertise responses and picks oneserver, as defined in Section 18.2.9 of RFC 8415. The clientSHOULD NOT pick a server that does not advertise an address in the requestedquadrant(s). The client then sends a Request message that includes the IA_LLcontainer option with the LLADDR option copied from the Advertise message sentby the chosen server. It includes the preferred SLAP quadrant(s) in a new QUADIA_LL option.
4. Upon reception of a Request message with an IA_LL container option, the serverassigns requested addresses. The server MAY alter the allocation at this time(e.g., by reducing the address block). It then generates and sends a Replymessage back to the client. Upon receiving a Reply message, the client parsesthe IA_LL container option and may start using all provided addresses. Note thata client that has included a Rapid Commit option in the Solicitmessage may receive aReply message in response to the Solicit message and skip theAdvertise and Request message steps above(following standard DHCPv6 procedures).
5. The client is expected to periodically renew the link-layer addresses, asgoverned by T1 and T2 timers. This mechanism can be administratively disabled bythe server sending "infinity" as the T1 and T2 values (see Section 7.7 of RFC 8415). The client sends a Renew option after T1. It includes thepreferred SLAP quadrant(s) in the new QUAD IA_LL option, so in case the serveris unable to extend the lifetime on the existing address(es), the preferredquadrants are known for the allocation of any "new" (i.e., different) addresses.
6. The server responds with a Reply message with an IA_LL option that includes anLLADDR option with extended lifetime.

+--------+                  +--------+                     +--------+
| 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. Relay-forward               |
   |                            | (Request(IA_LL(LLADDR)),QUAD)->|
   |                            |                                |
   |                            |<--7. Relay-reply               |
   |                            |   (Reply(IA_LL(LLADDR)))-------+
   |<--8. Reply(IA_LL(LLADDR))--+                                |
   |                            |                                |
   .                            .                                .
   .                    (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))-+                                |
   |                            |                                |

1. Link-layer addresses (i.e., MAC addresses) are assigned in blocks. The smallestblock is a single address. To request an assignment, the client sends a Solicitmessage with an IA_LL option in the message. The IA_LL option MUST contain anLLADDR option.
2. The DHCP relay receives the Solicit message and encapsulates it in aRelay-forward message. The relay, based on local knowledge and policies,includes in the Relay-forward message the QUAD option with the preferredquadrant. The relay might know which quadrant to request based on localconfiguration (e.g., the served network contains IoT devices only, thusrequiring ELI/SAI) or other means. Note that if a client sends multipleinstances of the IA_LL option in the same message, the DHCP relay MAY onlyadd a single instance of the QUAD option.
3. Upon receiving a relayed message containing an IA_LL option, the server inspectsthe contents for instances of OPTION_SLAP_QUAD in both the Relay-forward messageand the client's message payload. Depending on the server's policy, theinstance of the option to process is selected (see the end of thissection). For each of the entries in OPTION_SLAP_QUAD, in order of thepreference field (highest to lowest), the server checks if it has a configuredMAC address pool matching the requested quadrant identifier and an availablerange of addresses of the requested size. If suitable addresses are found, theserver sends back an Advertise message with an IA_LL option containing an LLADDRoption that specifies the addresses being offered. This message is sent to theRelay in a Relay-reply message. If the server supports the semantics of thepreferred quadrant included in the QUAD option and manages a block of addressesbelonging to a requested quadrant, then the addresses being offered MUSTbelong to a requested quadrant. The server SHOULD apply the contents of therelay's supplied QUAD option for all of the client's IA_LLs, unless configuredto do otherwise.
4. The relay sends the received Advertise message to the client.
5. The client waits for available servers to send Advertise responses and picks oneserver, as defined in Section 18.2.9 of RFC 8415. The client then sends a Request message that includes the IA_LL containeroption with the LLADDR option copied from the Advertise message sent by thechosen server.
6. The relay forwards the received Request in a Relay-forward message. It adds, in theRelay-forward, a QUAD IA_LL option with the preferred quadrant.
7. Upon reception of the forwarded Request message with IA_LL container option, theserver assigns requested addresses. The server MAY alter the allocation at thistime. It then generates and sends a Reply message in a Relay-replymessage back to therelay.
8. Upon receiving a Reply message, the client parses the IA_LL container option andmay start using all provided addresses.
9. The client is expected to periodically renew the link-layer addresses, asgoverned by T1 and T2 timers. This mechanism can be administratively disabled bythe server sending "infinity" as the T1 and T2 values (see Section 7.7 of RFC 8415). The client sends a Renew option after T1.
10. This message is forwarded by the relay in a Relay-forward message, including a QUADIA_LL option with the preferred quadrant.
11. The server responds with a Reply message, including an LLADDR option withextended lifetime. This message is sent in a Relay-reply message.
12. The relay sends the Reply message back to the client.

    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   quadrant-1  |    pref-1     |   quadrant-2  |    pref-2     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  quadrant-n-1 |   pref-n-1    |   quadrant-n  |    pref-n     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           

option-code

OPTION_SLAP_QUAD (140).

option-len

2 * number of included (quadrant, preference). This is a 2-byte field containing thetotal length of all (quadrant, preference) pairs included in the option.

quadrant-n

Identifier of the quadrant (0: AAI, 1: ELI, 2: Reserved by IEEE[IEEEStd802c], and 3: SAI). Each quadrantMUST only appear once at most in the option. This is a 1-byte field.

pref-n

Preference associated to quadrant-n. A higher value means a more preferredquadrant. This is a 1-byte field.

Value:

140

Description:

OPTION_SLAP_QUAD

Client ORO:

No

Singleton Option:

Yes

Reference:

RFC 8948

[RFC2119]

S. Bradner, "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]

B. Leiba, "Ambiguity 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>.

[RFC8415]

T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, 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>.

[RFC8947]

Universidad Carlos III de Madrid, B Volz, T Mrugalski, and CJ Bernardos, "Link-Layer Address Assignment Mechanism for DHCPv6", RFC 8947, DOI 10.17487/RFC8947, December 2020,
<https://www.rfc-editor.org/info/rfc8947>.

[IEEE-P802.1CQ-Project]

IEEE, "P802.1CQ - Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment",
<https://standards.ieee.org/project/802_1CQ.html>.

[IEEEStd802]

IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE Std 802-2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014,
<https://doi.org/10.1109/IEEESTD.2014.6847097>.

[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, DOI 10.1109/IEEESTD.2017.8016709, August 2017,
<https://doi.org/10.1109/IEEESTD.2017.8016709>.

[RFC7227]

D. Hankins, T. Mrugalski, M. Siodelski, S. Jiang, 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]

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

[RFC7548]

M. Ersue, D. Romascanu, J. Schoenwaelder, and A. Sehgal, "Management of Networks with Constrained Devices: Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015,
<https://www.rfc-editor.org/info/rfc7548>.

[RFC8200]

S. Deering, 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>.

• Type of IoT deployment: For example, industrial, domestic, rural, etc. For small deployments, such as domestic ones, the IoT device itself can decide to use the AAI quadrant (this might not even involve the use of DHCP, by the 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 coexist, the IoT can decide to use the ELI or SAI quadrants.
• Mobility: If the IoT device can move, then it might prefer to 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.
• Managed/Unmanaged: Depending on whether the IoT device is managed during its lifetime or cannot be reconfigured [RFC 7548], 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 (e.g., to avoid potential collisions in the future).
• Operation / Battery Lifetime: Depending on the expected lifetime of the device, a different quadrant might be preferred (as before, to minimize potential address collisions in the future).

• Type of network the device is connected: public, work, home.
• Trusted network: Yes/No.
• First time visited network: Yes/No.
• Network geographical location.
• Mobility: Yes (the device might change its network attachment point) / No (thedevice is not going to change its network attachment point).
• Operating System (OS) network profile, including security/trust-relatedparameters: Most modern OSs keep metadata associated with the networks they canattach to as, for example, the level of trust the user or administrator assignsto the network. This information is used to configure how the device behaves interms of advertising itself on the network, firewall settings, etc.But this information can also be used to decide whether or not to configure alocal MAC address, from which SLAP quadrant it should be assigned, and howoften it may be assigned.
• Triggers coming from applications regarding location privacy: An app mightrequest that the OS maximize location privacy (due to the nature of theapplication), and this might require the OS to force the use of a local MACaddress or the local MAC address to be changed.

• Migratable VM: If the function implemented by the VM is subject to be moved toanother physical server or not, this has an impact on the preference for theSLAP quadrant, as the ELI and SAI quadrants are better suited for supportingmigration in a large data center.
• VM connectivity characteristics: For example, standalone, part of a pool, and part of aservice graph/chain. If the connectivity characteristics of the VM are known,this can be used by the hypervisor to select the best SLAP quadrant.

Carlos J. Bernardos

Alain Mourad