RFC 8948 | DHCPv6 SLAP Quadrant Selection | December 2020 |
Bernardos & Mourad | Standards Track | [Page] |
The IEEE originally structured the 48-bit Media Access Control (MAC) address space in such a way that half of it was reserved for local use. In 2017, the IEEE published a new standard (IEEE Std 802c) with a new optional Structured Local Address Plan (SLAP). It specifies different assignment approaches in four specified regions of the local MAC address space.¶
The IEEE is developing protocols to assign addresses (IEEE P802.1CQ). There is also work in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments.¶
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 may allocate MAC addresses in the quadrant requested by the relay or client. A new DHCPv6 option (QUAD) is defined for this purpose.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8948.¶
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.¶
The IEEE structures the 48-bit MAC address space in such a way that half of it is reserved for local use (where the Universal/Local (U/L) bit is set to 1). In 2017, the IEEE published a new standard [IEEEStd802c] that defines a new 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 Table 1 for details):¶
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 Assigned | AAI |
10 | 1 | 0 | Reserved | Reserved |
The IEEE is developing mechanisms to assign addresses [IEEE-P802.1CQ-Project]. And [RFC8947] specifies a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments. 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 may allocate the MAC addresses in the quadrant requested by the relay or client.¶
In the following, we describe two application scenarios in which a need arises to assign local MAC addresses according to preferred SLAP quadrants.¶
Today, most Wi-Fi 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 particularly in the following two scenarios:¶
In large-scale virtualization environments, thousands of virtual machines (VMs) are active. These VMs are typically managed by a hypervisor, which is 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 that available DHCP servers assign one or more MAC addresses (an address block). The hypervisor does not use those addresses for itself, but rather it 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:¶
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 [RFC8415] also applies here. Additionally, the following definitions are updated for this document.¶
Next, we describe the protocol operations for a client to select a preferred SLAP quadrant using the DHCPv6 signaling procedures described in [RFC8947]. The signaling flow is shown in Figure 2.¶
The client SHOULD check if the received MAC address comes from one of the requested quadrants. It MAY repeat the process selecting a different DHCP server.¶
Next, we describe the protocol operations for a relay to select a preferred SLAP quadrant using the DHCPv6 signaling procedures described in [RFC8947]. 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.¶
The server SHOULD implement a configuration parameter to deal with the case where the client's DHCP message contains an instance of OPTION_SLAP_QUAD 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 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 to use/configure and MAY decide based on that whether to use/configure the received address.¶
The QUAD option is used to specify the preferences for the selected quadrants within an IA_LL. The option MUST be encapsulated either in the IA_LL-options field of an IA_LL option or in a Relay-forward message.¶
The format of the QUAD option is:¶
A quadrant identifier value MUST only appear, at most, once in the option. If an option includes more than one occurrence of the same quadrant identifier, only the first occurrence is processed, and the rest MUST be ignored by the server.¶
If the same preference value is used for more than one quadrant, the server MAY select which quadrant should be preferred (if the server can assign addresses from all or some of the quadrants with the same assigned preference). Note that this is not a simple list of quadrants ordered by preference with no preference value, but a list of quadrants with explicit preference values. This way it can support the case whereby a client really has no preference between two or three quadrants, leaving the decision to the server.¶
If the client or relay agent provides the OPTION_SLAP_QUAD, the server MUST use the quadrant-n/pref-n values to order the selection of the quadrants. If the server can provide an assignment from one of the specified quadrants, it SHOULD proceed with the assignment. If the server does not have a configured address pool matching any of the specified quadrant-n fields or if the server has a configured address pool of the correct quadrant but no available addresses, it MUST return the IA_LL option containing a status of NoAddrsAvail.¶
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 one set of values).¶
For cases where a server may not be configured to have pools for the client or relay quadrant preferences, clients and relays SHOULD specify all quadrants in the QUAD option to assure the client gets an address (or addresses) -- if any are available. Specifying all quadrants also results in a QUAD option supporting server responding like a non-QUAD option supporting server, i.e., an address (or addresses) from any available quadrants can be returned.¶
IANA has assigned the QUAD (140) option code from the "Option Codes" subregistry of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained at <http://www.iana.org/assignments/dhcpv6-parameters>:¶
See [RFC8415] and [RFC7227] for the DHCPv6 security and privacy considerations. See [RFC8200] for the IPv6 security considerations.¶
Also, see [RFC8947] for security considerations regarding link-layer address assignments using DHCP.¶
This appendix describes some examples of how the quadrant preference mechanisms could be used.¶
First, let's take 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 make the decision:¶
The previous parameters are considerations that the device vendor/administrator may wish to use when defining the 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 preconfigured preferences.¶
We now take the Wi-Fi 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, the 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 to use for the local MAC address configuration, but also when to perform a change of address (e.g., it might be needed to change address several times). This information includes, but it is not limited to:¶
This information can be used by the device to select the SLAP quadrant. For example, if the device is moving around (e.g., while connected to a public network in an airport), it is likely that it might change access points several times; therefore, it is best to minimize the chances of address collision, using the SAI or AAI quadrants. If the device is not expected to move and is 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 quadrant.¶
Additionally, the information can also be used to trigger subsequent changes of MAC address to enhance location privacy. Besides, changing the SLAP quadrant might also be used as an additional enhancement to make it harder to track the user location.¶
Last, if we consider the data-center scenario, a hypervisor might request local MAC addresses 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 or virtualization infrastructure manager running on top of the hypervisor. This information might include, but is not limited to:¶
The authors would like to thank Bernie Volz for his very valuable comments on this document. We also want to thank Ian Farrer, Tomek Mrugalski, Éric Vyncke, Tatuya Jinmei, Carl Wallace, Ines Robles, Ted Lemon, Jaime Jimenez, Robert Wilton, Benjamin Kaduk, Barry Leiba, Alvaro Retana, and Murray Kucherawy for their very detailed and helpful reviews. And thanks to Roger Marks and Antonio de la Oliva for comments related to IEEE work and references.¶
The work in this document has been supported by the H2020 5GROWTH (Grant 856709) and 5G-DIVE projects (Grant 859881).¶