RFC 8948

Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6

📅 published December 2020, from ietf

Abstract 🎀

okay so the IEEE originally split up the 48-bit MAC address space so that half of it was set aside for local use 🫶 Then in 2017 they dropped IEEE Std 802c, which adds an optional Structured Local Address Plan (SLAP) that sorts that local space into four regions with different assignment approaches ✨

The IEEE is also building protocols to assign addresses (IEEE P802.1CQ), and over in the IETF there's work on a mechanism that extends DHCPv6 so it can handle these local MAC assignments 🌸

This doc proposes DHCPv6 extensions so a client or a relay can say which SLAP quadrant they'd prefer, and the server can then hand out MAC addresses from that quadrant 💅 A new DHCPv6 option called QUAD is defined for exactly this 💖

Status of This Memo 📜

This is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, and it got public review before being approved for publication by the Internet Engineering Steering Group (IESG) ✨ If you want more on Internet Standards, check Section 2 of RFC 7841 🧚

Errata, the current status, and how to give feedback are all 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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🫶

Table of Contents 🍓

1.  Introduction
  1.1.  Problem Statement
    1.1.1.  Wi-Fi (IEEE 802.11) Devices
    1.1.2.  Hypervisor: Functions That Are and Are Not Migratable
2.  Terminology
3.  DHCPv6 Extensions
  3.1.  Address Assignment from the Preferred SLAP Quadrant
        Indicated by the Client
  3.2.  Address Assignment from the Preferred SLAP Quadrant
        Indicated by the Relay
4.  DHCPv6 Option Definition
  4.1.  QUAD Option
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  Example Uses of Quadrant Selection Mechanisms
Acknowledgments
Authors' Addresses

Title Block 👑

Let's get the basics out of the way first 🎀

  • Document: RFC 8948, Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6
  • Authors: CJ. Bernardos (UC3M) and A. Mourad (InterDigital) 💖
  • Category: Standards Track ✨
  • ISSN: 2070-1721 🦋
  • Date: December 2020 📅
  • Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🫶

1. Introduction ✨

okay so the IEEE structures the 48-bit MAC address space so that half of it is reserved for local use (that's where the Universal/Local (U/L) bit is set to 1) 🌸 In 2017, the IEEE published a new standard [IEEEStd802c] that defines an optional Structured Local Address Plan (SLAP), which splits the local MAC address space into four regions. These four regions are called SLAP quadrants, and here's the quick version (see Figure 1 and Table 1 for the details) 💅

  • In SLAP Quadrant 01, Extended Local Identifier (ELI) MAC addresses are assigned based on a 24-bit Company ID (CID), which is handed out by the IEEE Registration Authority (RA) 🎀 The remaining bits are specified as an extension by the CID assignee, or by a protocol the CID assignee designates 🧚
  • 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. Several protocols for assigning SAIs may be specified in IEEE standards, and they can coexist by each one getting its own limited subspace to assign from 🦋
  • 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, so AAI addresses in that range should not be assigned 🙈 For 48-bit MAC addresses, 44 bits are available. 💜
  • SLAP Quadrant 10 is "Reserved for future use", where MAC addresses may be assigned using new methods that haven't been defined yet, or until then by an administrator, the same way 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)

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

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

Table 1: SLAP Quadrants 🍓

1.1. Problem Statement 🔥

The IEEE is developing mechanisms to assign addresses [IEEE-P802.1CQ-Project] 🫶 And [RFC8947] specifies a new mechanism that extends DHCPv6 operation to handle local MAC address assignments ✨ This document proposes DHCPv6 extensions so a DHCPv6 client or relay can indicate a preferred SLAP quadrant to the server, and the server can then allocate MAC addresses from the quadrant the relay or client asked for 💅

Next up are two application scenarios where you'd actually need to assign local MAC addresses based on preferred SLAP quadrants 👑

1.1.1. Wi-Fi (IEEE 802.11) Devices 📶

Right now, most Wi-Fi devices come with a "burned-in" MAC address that's pulled from the universal address space using a 24-bit Organizationally Unique Identifier (OUI), which is assigned to IEEE 802 interface vendors 🌸 But lately the need to assign local MAC addresses (instead of universal ones) has popped up, mainly in these two scenarios:

  • IoT (Internet of Things): these are generally made of constrained devices [RFC7228], which have limits on things like power and energy, memory, and processing 🔋 Think sensors and actuators for health or home automation. With so many of these devices around, manufacturers might like to give them temporary MAC addresses that only get used at first boot 🧚 Those temporary addresses would just be used to send the initial DHCP packets to available DHCP servers. IoT devices usually need a single MAC address per network interface. Once the server assigns a MAC address, the device would drop its temporary one 🦋 Home automation IoT devices typically don't move (though mobile smart health monitoring devices are on the rise, so keep an eye on that 👀). For this kind of device, basically any SLAP quadrant would work for assigning addresses, but ELI/SAI might be a better fit in some situations 💖 For example, the device might need an address from the CID assigned to the IoT communication device vendor, which makes the ELI quadrant the pick 🎀
  • Privacy: these days MAC addresses let people's locations get exposed, which makes it pretty easy to track where users move 😭 One idea for fixing this is using local random MAC addresses and changing them every time the user connects to a different network 🫣 In this scenario devices are usually mobile. Here, AAI is probably the best SLAP quadrant to assign from: it's the best fit for randomizing addresses, and the addresses don't have to survive when the device changes networks 💜

1.1.2. Hypervisor: Functions That Are and Are Not Migratable 🌈

In big virtualization environments, thousands of virtual machines (VMs) are active at once 🖥️ These VMs are usually managed by a hypervisor, which is in charge of spawning and stopping VMs as needed. The hypervisor is also usually in charge of assigning new MAC addresses to the VMs 💅 If there's a DHCP solution set up for that, the hypervisor acts as a DHCP client and asks the available DHCP servers to assign one or more MAC addresses (an address block). The hypervisor doesn't use those addresses for itself. It uses them to create new VMs with the right MAC addresses ✨ In very large data-center environments, which are what people typically use nowadays, the data center is expected to be split into different network regions, and each one manages its own local address space 🏢 In this setup, there are two possible situations that need to be handled 👀

  • Migratable functions: if a VM providing a given function needs to move to another region of the data center (for maintenance, resilience, end-user mobility, and so on), the VM's networking context has to move with it 🧳 That includes the VM's MAC address(es). Since assignments from the ELI/SAI SLAP quadrants are governed by the rules in IEEE Std 802c, they're better for keeping MAC addresses globally unique across the data center 🔒
  • Functions that are not migratable: if a VM will not be moved to another region of the data center, there are no requirements attached to its MAC address 🙌 In this case it's simpler to allocate it from the AAI SLAP quadrant, which doesn't need to be unique across multiple data centers. Each region can manage its own MAC address assignments without checking for duplicates globally 🌸

2. Terminology 📖✨

Okay bestie, first the ground rules 💅. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" carry their BCP 14 meaning ([RFC2119] [RFC8174]) only when they're written in all capitals, exactly like that. Lowercase ones are just regular words, so no drama. 🫶

Where it's relevant, the DHCPv6 terminology from [RFC8415] also applies here. On top of that, these definitions get updated for this doc 🌸

  • address: Unless specified otherwise, it's a link-layer (or MAC) address, as specified in [IEEEStd802]. The address is 6 or 8 bytes long. 🔢
  • address block: A bunch of consecutive link-layer addresses. It's written as a first address plus a number for how many extra addresses come after it. A single address can be shown as the address itself with zero extra addresses. 🧩
  • client: A node that wants to get link-layer addresses. It implements the basic DHCP mechanisms a DHCP client needs, as described in [RFC8415], and it supports the options (IA_LL and LLADDR) specified in [RFC8947] plus 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]. 💖
  • IA_LL: Identity Association for Link-Layer Address. It's an identity association (IA) used to request or assign link-layer addresses. Section 11.1 of [RFC8947] has the details on the IA_LL option. 🎀
  • LLADDR: The link-layer address option, used to request or assign a block of link-layer addresses. Section 11.2 of [RFC8947] has the details on the LLADDR option. 🦋
  • relay: A node that acts as a middleman, delivering DHCP messages between clients and servers. Based on local knowledge and policies, a relay may include the preferred SLAP quadrant in a QUAD option sent to the server. It implements basic DHCPv6 relay agent functionality, as described in [RFC8415]. 🧚
  • server: A node that manages link-layer address allocation and can respond to client queries. It implements basic DHCP server functionality, as described in [RFC8415], and supports the options (IA_LL and LLADDR) specified in [RFC8947] plus 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]. 👑

3. DHCPv6 Extensions 🌈

3.1. Address Assignment from the Preferred SLAP Quadrant Indicated by the Client 🦋

Next up, we go through how a client picks a preferred SLAP quadrant using the DHCPv6 signaling procedures from [RFC8947] 💅 The whole flow is shown in Figure 2, and it's giving clean choreography 🧚

    +--------+                            +--------+
    | 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 2: DHCPv6 Signaling Flow (Client-Server)

Here's the step-by-step tea ☕

  1. Link-layer addresses (aka MAC addresses) get handed out in blocks, and the smallest block is a single address. To ask for one, the client sends a Solicit message with an IA_LL option inside it. The IA_LL option MUST contain an LLADDR option. To show its preferred SLAP quadrant(s), the IA_LL option also includes the new OPTION_SLAP_QUAD option in the IA_LL-option field, sitting right alongside the LLADDR option. 🎀
  2. When the server gets an IA_LL option in a Solicit message, it looks at what's in there. For each entry in the OPTION_SLAP_QUAD, going from highest to lowest preference value, the server checks whether it has a configured MAC address pool that matches the requested quadrant identifier and has an available range of addresses of the requested size. If it finds suitable addresses, it sends back an Advertise message with an IA_LL option holding an LLADDR option that says which addresses it's offering. If the server manages a block of addresses in a requested quadrant, the addresses it offers MUST belong to a requested quadrant. If the server doesn't have a pool that matches the client's request, it SHOULD still return the IA_LL option, with the offered addresses coming from a quadrant the server manages (picked according to local policy from whichever quadrants are available). And if the server has a pool in the right quadrant but no addresses left, it MUST return the IA_LL option containing a Status Code option with the status set to NoAddrsAvail. 🌸
  3. The client waits for available servers to send their Advertise responses, then picks one server, as defined in Section 18.2.9 of [RFC8415]. The client SHOULD NOT pick a server that doesn't advertise an address in the requested quadrant(s). After that, it sends a Request message with the IA_LL container option, copying the LLADDR option from the Advertise message of the chosen server. It includes the preferred SLAP quadrant(s) in a new QUAD IA_LL option. 💜
  4. When the server gets a Request message with an IA_LL container option, it assigns the requested addresses. The server MAY alter the allocation at this point (for example, by reducing the address block). Then it generates and sends a Reply message back to the client. When the client gets that Reply, it parses the IA_LL container option and may start using all of the provided addresses. Heads up: a client that put a Rapid Commit option in its Solicit message may get a Reply in response to the Solicit itself, and skip the Advertise and Request steps above (following standard DHCPv6 procedures). ⚡
  5. The client is expected to periodically renew its link-layer addresses, governed by the T1 and T2 timers. The server can turn this off administratively by sending "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). The client sends a Renew message after T1. It includes the preferred SLAP quadrant(s) in the new QUAD IA_LL option, so if the server can't extend the lifetime on the existing address(es), the preferred quadrants are already known for allocating any "new" (i.e., different) addresses. 🔄
  6. The server responds with a Reply message whose IA_LL option includes an LLADDR option with an extended lifetime. ✨

After the exchange, the client SHOULD check whether the received MAC address comes from one of the requested quadrants. If it doesn't, it MAY repeat the process and select a different DHCP server. 🙈

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

Okay bestie, next up is how a relay can pick a preferred SLAP quadrant using the DHCPv6 signaling from [RFC8947] 💅 This is super useful when a DHCPv6 server is running across a massive infrastructure that's split into different network regions, and each region might have its own needs 🌸 Here's the signaling flow, Figure 3:

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

Figure 3: DHCPv6 Signaling Flow (Client-Relay-Server)

  1. Link-layer addresses (aka MAC addresses) come in blocks 🧚 The tiniest block is just one address. To ask for some, the client sends a Solicit message with an IA_LL option in it. The IA_LL option MUST contain an LLADDR option 🔥
  2. The DHCP relay catches the Solicit and wraps it up in a Relay-forward message. Based on local knowledge and policies, the relay adds the QUAD option with the preferred quadrant to the Relay-forward message. It might know which quadrant to request from local configuration (e.g., the served network only has IoT devices, so it needs ELI/SAI) or from other means. Note that if a client sends multiple instances of the IA_LL option in the same message, the DHCP relay MAY only add a single instance of the QUAD option.
  3. Once the server gets a relayed message containing an IA_LL option, it checks for instances of OPTION_SLAP_QUAD in both the Relay-forward message and the client's message payload 👀 Depending on the server's policy, it picks which instance of the option to process (more on that at the end of this section). For each entry in OPTION_SLAP_QUAD, in order of the preference field (highest to lowest), the server checks whether it has a configured MAC address pool that matches the requested quadrant identifier and an available range of addresses of the requested size. If suitable addresses turn up, the server sends back an Advertise message with an IA_LL option containing an LLADDR option that specifies the addresses being offered. This goes to the relay in a Relay-reply message. If the server supports the semantics of the preferred quadrant included in the QUAD option and manages a block of addresses belonging to a requested quadrant, then the addresses being offered MUST belong to a requested quadrant. The server SHOULD apply the contents of the relay's supplied QUAD option for all of the client's IA_LLs, unless it's configured to do otherwise.
  4. The relay passes the received Advertise message along to 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]. Then it 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.
  6. The relay forwards the received Request in a Relay-forward message. It adds a QUAD IA_LL option with the preferred quadrant to the Relay-forward.
  7. When the forwarded Request message with the IA_LL container option arrives, the server assigns the requested addresses. The server MAY alter the allocation at this time 🔄 Then it generates a Reply message and sends it back to the relay in a Relay-reply message.
  8. When the client gets a Reply message, it parses the IA_LL container option and may start using all of the provided addresses ✨
  9. The client is expected to periodically renew the link-layer addresses, as governed by the T1 and T2 timers. The server can administratively disable this mechanism by sending "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). The client sends a Renew option after T1 ⏰
  10. This message gets forwarded by 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 that includes an LLADDR option with an extended lifetime. This message is sent in a Relay-reply message.
  12. The relay sends the Reply message back to the client 🥳

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 tells the server to process either the client's instance or the relay's instance of the QUAD option. It is RECOMMENDED that the default for this parameter is to process the client's instance of the option 💜

The client MAY check whether the received MAC address belongs to a quadrant it is willing to use or configure, and MAY decide based on that whether to use or configure the received address 🫶

4. DHCPv6 Option Definition 🎀

4.1. QUAD Option ✨

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

Here's the format of the QUAD option:

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

Figure 4: QUAD Option Format

Here's what each field means 👇

  • option-code: OPTION_SLAP_QUAD (140).
  • option-len: 2 * number of included (quadrant, preference). This is a 2-byte field containing the total 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 quadrant MUST only appear once at most in the option. This is a 1-byte field.
  • pref-n: Preference associated with quadrant-n. A higher value means a more preferred quadrant. This is a 1-byte field.

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 where 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 make sure the client gets an address (or addresses), if any are available. Specifying all quadrants also means the QUAD option supports a server responding like a non-QUAD option supporting server, i.e., an address (or addresses) from any available quadrants can be returned 🌈

5. IANA Considerations 🦋

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>:

Value:  140
Description:  OPTION_SLAP_QUAD
Client ORO:  No
Singleton Option:  Yes
Reference:  RFC 8948
  1. Security Considerations 🔐✨

Okay so bestie, security is serious business, but this part is actually pretty chill! 💅 For the DHCPv6 security and privacy stuff, you check out [RFC8415] and [RFC7227]. For the IPv6 security considerations, it's [RFC8200]. 🦋

And also, if you care about security for link-layer address assignments using DHCP, go read [RFC8947]. It's giving "read the other doc" energy 🙈💜

  1. References 📚🎀

7.1. Normative References 💖

These are the ones you NEED to read, no skipping, periodt 💅

7.2. Informative References 🌸

These ones are extra juicy background reading 🧚

Appendix A. Example Uses of Quadrant Selection Mechanisms 🌈

This appendix is a whole vibe of examples for how the quadrant preference mechanisms could be used 🦋

First, let's take an IoT scenario! An IoT device might decide on its own which SLAP quadrant it wants to use to get a local MAC address, using these details to decide:

  • Type of IoT deployment: For example, industrial, domestic, rural, etc. For small deployments like domestic ones, the IoT device itself can pick the AAI quadrant (this might not even involve DHCP, since the device could just configure a random address it computes itself 🤯). For big deployments, like industrial or rural ones, where thousands of devices might coexist, the IoT can go with the ELI or SAI quadrants 💅
  • Mobility: If the IoT device can move, it might prefer the SAI or AAI quadrants to keep address collisions low when it moves to another network. If the device is known to stay put, then the ELI is probably the most suitable one 📍
  • Managed/Unmanaged: Depending on whether the IoT device is managed during its lifetime or cannot be reconfigured [RFC7548], the decision of which quadrant is more appropriate might be different. For example, if the IoT device can be managed (e.g., configured) and network topology changes might happen during its lifetime (e.g., due to changes in the deployment, like 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) 🔋

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 🧸

Now we take the Wi-Fi device scenario! Say 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 change address (e.g., it might be needed to change address several times). This information includes, but is not limited to:

  • Type of network the device is connected to: 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 (the device is not going to change its network attachment point).
  • Operating System (OS) network profile, including security/trust-related parameters: Most modern OSs keep metadata associated with the networks they can attach to, such as the level of trust the user or administrator assigns to the network. This information is used to configure how the device behaves in terms of advertising itself on the network, firewall settings, etc. But this information can also be used to decide whether or not to configure a local MAC address, which SLAP quadrant it should be assigned from, and how often it may be assigned 🔐
  • Triggers coming from applications regarding location privacy: An app might request that the OS maximize location privacy (due to the nature of the application), and this might require the OS to force the use of a local MAC address or the local MAC address to be changed 📱

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 to 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's location 🫣

Last but not least, let's look at 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:

  • Migratable VM: If the function implemented by the VM is subject to being moved to another physical server or not, this has an impact on the preference for the SLAP quadrant, as the ELI and SAI quadrants are better suited for supporting migration in a large data center 🏢
  • VM connectivity characteristics: For example, standalone, part of a pool, and part of a service graph/chain. If the connectivity characteristics of the VM are known, the hypervisor can use them to select the best SLAP quadrant 🧚

Acknowledgments 💖

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

Authors' Addresses 🦋

Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 28911 Leganes, Madrid 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/

📦 where this page comes from