Movatterモバイル変換

[0]ホーム
URL:

RFC 8948DHCPv6 SLAP Quadrant SelectionDecember 2020
Bernardos & MouradStandards Track[Page]
Stream:
Internet Engineering Task Force (IETF)
RFC:
8948
Category:
Standards Track
Published:
ISSN:
2070-1721
Authors:
CJ. Bernardos
UC3M
A. Mourad
InterDigital

RFC 8948

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

Abstract

The IEEE originally structured the 48-bit Media Access Control (MAC) address space in such a way that halfof it was reserved for local use. In 2017, the IEEE published a new standard (IEEEStd 802c) with a new optional Structured Local Address Plan (SLAP). Itspecifies different assignment approaches in four specified regions of the localMAC address space.

The IEEE is developing protocols to assign addresses (IEEEP802.1CQ). There is also workin the IETF on specifying a new mechanism that extends DHCPv6 operation tohandle the local MAC address assignments.

This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 clientor a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so thatthe server may allocate MAC addresses in the quadrant requested by the relay orclient. A new DHCPv6 option (QUAD) is defined for this purpose.

Status of This Memo

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 athttps://www.rfc-editor.org/info/rfc8948.

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

The IEEE structures the 48-bit MAC address space in such a way that half of it isreserved for local use (where the Universal/Local (U/L) bit is set to 1). In2017, the IEEE published a new standard[IEEEStd802c]that defines a new optional Structured Local Address Plan (SLAP) thatspecifies different assignment approaches in four specified regions of the localMAC address space. These four regions, called SLAP quadrants, are brieflydescribed below (seeFigure 1 andTable 1 for details):

       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)
Table 1:SLAP Quadrants
QuadrantY-bitZ-bitLocal Identifier TypeLocal Identifier
0101Extended LocalELI
1111Standard AssignedSAI
0000Administratively AssignedAAI
1010ReservedReserved

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 the local MACaddress assignments.This document proposes extensions to DHCPv6 protocols toenable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrantto the server so that the server may allocate the MAC addresses in the quadrantrequested by the relay or client.

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

1.1.1.Wi-Fi (IEEE 802.11) Devices

Today, most Wi-Fi devices come with interfaces that have a "burned-in" MACaddress, allocated from the universal address space using a 24-bitOrganizationally Unique Identifier (OUI) (assigned to IEEE 802 interfacevendors). However, recently, the need to assign local (instead of universal) MACaddresses has emerged particularly in the following two scenarios:

  • IoT (Internet of Things): In general, composed of constrained devices[RFC7228] 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.

1.1.2.Hypervisor: Functions That Are and Are Not Migratable

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

  • Migratable functions: If a VM (providing a given function) needs to be migratedto another region of the data center (e.g., for maintenance, resilience,end-user mobility, etc.), the VM's networking context needs to migrate with theVM. This includes the VM's MAC address(es). Since the assignments from theELI/SAI SLAP quadrants are governed by rules per IEEE Std 802c, they are moreappropriate 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 thedata center, there are no requirements associated with its MAC address. In thiscase, it is simpler to allocate it from the AAI SLAP quadrant, which doesnot need to be unique across multiple data centers (i.e., each region canmanage its own MAC address assignment without checking for duplicatesglobally).

2.Terminology

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

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

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[RFC8415], and supports the options (IA_LL and LLADDR) specified in[RFC8947] 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].
IA_LL
Identity Association for Link-Layer Address, an identity association (IA) used to request or assign link-layer addresses.Section 11.1 of [RFC8947] 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 [RFC8947] 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[RFC8415].
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[RFC8415], and supports the options (IA_LL and LLADDR) specified in[RFC8947] 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].

3.DHCPv6 Extensions

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

Next, we describe the protocol operations for a client to select a preferredSLAP quadrant using the DHCPv6 signaling procedures described in[RFC8947]. The signaling flow is shown inFigure 2.

 +--------+                            +--------+ | 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)
  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 optionMUST 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 offeredMUSTbelong to a requested quadrant. If the server does not have a configured addresspool matching the client's request, itSHOULD 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, itMUST 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 inSection 18.2.9 of [RFC8415]. 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 serverMAY 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 (seeSection 7.7 of [RFC8415]). 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.

The clientSHOULD check if the received MAC address comes from one of therequested quadrants. ItMAY repeat the process selecting a different DHCP server.

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

Next, we describe the protocol operations for a relay to select a preferredSLAP quadrant using the DHCPv6 signaling procedures described in[RFC8947]. This is useful when a DHCPv6 server isoperating over a large infrastructure split in different network regions, whereeach region might have different requirements. The signaling flow is shown inFigure 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 (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 optionMUST 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 relayMAY 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 offeredMUSTbelong to a requested quadrant. The serverSHOULD 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 inSection 18.2.9 of [RFC8415]. 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 serverMAY 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 (seeSection 7.7 of [RFC8415]). 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.

The serverSHOULD implement a configuration parameter to deal with the casewhere the client's DHCP message contains an instance of OPTION_SLAP_QUAD andthe relay adds a second instance in its Relay-forward message. This parameterconfigures the server to process either the client's or the relay's instance ofoption QUAD. It isRECOMMENDED that the default for such a parameter is toprocess the client's instance of the option.

The clientMAY check if the received MAC address belongs to a quadrant it iswilling to use/configure andMAY decide based on that whether to use/configurethe received address.

4.DHCPv6 Option Definition

4.1.QUAD Option

The QUAD option is used to specify the preferences for the selected quadrantswithin an IA_LL. The optionMUST be encapsulated either in the IA_LL-optionsfield 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           |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |   quadrant-1  |    pref-1     |   quadrant-2  |    pref-2     |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   .                                                               .   .                                                               .   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |  quadrant-n-1 |   pref-n-1    |   quadrant-n  |    pref-n     |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4:QUAD Option Format
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.

A quadrant identifier valueMUST only appear, at most, once in the option. Ifan option includes more than one occurrence of the same quadrant identifier,only the first occurrence is processed, and the restMUST be ignored by theserver.

If the same preference value is used for more than one quadrant, the serverMAY select which quadrant should be preferred (if the server can assignaddresses from all or some of the quadrants with the same assignedpreference). Note that this is not a simple list of quadrants ordered bypreference with no preference value, but a list of quadrants with explicitpreference values. This way it can support the case whereby a client reallyhas no preference between two or three quadrants, leaving the decision to theserver.

If the client or relay agent provides the OPTION_SLAP_QUAD, the serverMUST usethe quadrant-n/pref-n values to order the selection of the quadrants. If theserver can provide an assignment from one of the specified quadrants, itSHOULDproceed with the assignment. If the server does not have a configured addresspool matching any of the specified quadrant-n fields or if the server has aconfigured address pool of the correct quadrant but no available addresses,itMUST return the IA_LL option containing a status of NoAddrsAvail.

There is no requirement that the client or relay agent order the quadrant/prefvalues in any specific order; hence, serversMUST NOT assume thatquadrant-1/pref-1 have the highest preference (except if there is only one set ofvalues).

For cases where a server may not be configured to have pools for the client orrelay quadrant preferences, clients and relaysSHOULD specify all quadrants inthe QUAD option to assure the client gets an address (or addresses) -- if anyare available. Specifying all quadrants also results in a QUAD option supportingserver responding like a non-QUAD option supporting server, i.e., an address (oraddresses) 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

6.Security Considerations

See[RFC8415] and[RFC7227] for the DHCPv6security and privacy considerations. See[RFC8200] for the IPv6security considerations.

Also, see[RFC8947] for security considerationsregarding link-layer address assignments using DHCP.

7.References

7.1.Normative References

[RFC2119]
Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels",BCP 14,RFC 2119,DOI 10.17487/RFC2119,,<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B.,"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words",BCP 14,RFC 8174,DOI 10.17487/RFC8174,,<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,,<https://www.rfc-editor.org/info/rfc8415>.
[RFC8947]
Volz, B., Mrugalski, T., and CJ. Bernardos,"Link-Layer Address Assignment Mechanism for DHCPv6",RFC 8947,DOI 10.17487/RFC8947,,<https://www.rfc-editor.org/info/rfc8947>.

7.2.Informative References

[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,,<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,,<https://doi.org/10.1109/IEEESTD.2017.8016709>.
[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,,<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,,<https://www.rfc-editor.org/info/rfc7228>.
[RFC7548]
Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. Sehgal,"Management of Networks with Constrained Devices: Use Cases",RFC 7548,DOI 10.17487/RFC7548,,<https://www.rfc-editor.org/info/rfc7548>.
[RFC8200]
Deering, S. and R. Hinden,"Internet Protocol, Version 6 (IPv6) Specification",STD 86,RFC 8200,DOI 10.17487/RFC8200,,<https://www.rfc-editor.org/info/rfc8200>.

Appendix A.Example Uses of Quadrant Selection Mechanisms

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

First, let's take an IoT scenario as an example. An IoT device might decide onits own the SLAP quadrant it wants to use to obtain a local MAC address, usingthe following information to make the decision:

The previous parameters are considerations that the device vendor/administratormay 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 resourceconstrained, so there may only be a simple decision-making process based onpreconfigured preferences.

We now take the Wi-Fi device scenario, considering, for example, that a laptopor smartphone connects to a network using its built-in MAC address. Due toprivacy/security concerns, the device might want to configure a local MACaddress. The device might use different parameters and context information todecide, not only which SLAP quadrant to use for the local MAC addressconfiguration, but also when to perform a change of address (e.g., it might beneeded to change address several times). This information includes, but it isnot limited to:

This information can be used by the device to select the SLAP quadrant. Forexample, if the device is moving around (e.g., while connected to a publicnetwork in an airport), it is likely that it might change access points severaltimes; therefore, it is best to minimize the chances of address collision,using the SAI or AAI quadrants. If the device is not expected to moveand is attached to atrusted network (e.g., in some scenarios at work), then it is probably best to select the ELIquadrant. These are just some examples of how to use this information to selectthe quadrant.

Additionally, the information can also be used to trigger subsequent changes ofMAC address to enhance location privacy. Besides, changing the SLAPquadrant might also be used as an additional enhancement to make it harder to trackthe user location.

Last, if we consider the data-center scenario, a hypervisor might request localMAC addresses be assigned to virtual machines. As in the previous scenarios,the hypervisor might select the preferred SLAP quadrant using informationprovided by the cloud management system or virtualization infrastructuremanager running on top of the hypervisor. This information might include,but is not limited to:

Acknowledgments

The authors would like to thankBernie Volz forhis very valuable comments on this document. We also want to thankIan Farrer,Tomek Mrugalski,Éric Vyncke,Tatuya Jinmei,Carl Wallace,Ines Robles,Ted Lemon,Jaime Jimenez,Robert Wilton,Benjamin Kaduk,Barry Leiba,Alvaro Retana, andMurray Kucherawyfor their very detailed and helpful reviews. And thanks toRoger Marks andAntonio de la Oliva for comments related toIEEE work and references.

The work in this document has been supported by the H2020 5GROWTH (Grant856709) and 5G-DIVE projects (Grant 859881).

Authors' Addresses

Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
28911Leganes, 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/
[8]ページ先頭
©2009-2026 Movatter.jp