DHC WG
Internet Engineering Task Force (IETF) CJ. Bernardos
Internet-Draft
Request for Comments: 8948 UC3M
Intended status:
Category: Standards Track A. Mourad
Expires: April 16, 2021
ISSN: 2070-1721 InterDigital
October 13,
November 2020
SLAP quadrant selection option
Structured Local Address Plan (SLAP) Quadrant Selection Option for
DHCPv6
draft-ietf-dhc-slap-quadrant-12
Abstract
The IEEE originally structured the 48-bit MAC 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 Structured Local Address Plan" 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 work 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, 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of six months RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2021.
https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 Statement
1.1.1. WiFi Wi-Fi (IEEE 802.11) devices . . . . . . . . . . . . . 4 Devices
1.1.2. Hypervisor: migratable vs non-migratable functions . 5 Functions That Are and Are Not Migratable
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. DHCPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Address Assignment from the Preferred SLAP Quadrant
Indicated by the Client . . . . . . . . . . . . . . . . . 7
3.2. Address Assignment from the Preferred SLAP Quadrant
Indicated by the Relay . . . . . . . . . . . . . . . . . . . . . . . . 9
4. DHCPv6 Option Definition . . . . . . . . . . . . . . . . . . 11
4.1. Quad option . . . . . . . . . . . . . . . . . . . . . . . 11 QUAD Option
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1.
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2.
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Example Uses of Quadrant Selection Mechanisms examples . . . . . . . 15
Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The IEEE structures the 48-bit MAC address space in such a way that
half of it was is reserved for local use (where the Universal/Local -- U/L -- (U/L)
bit is set to 1). In 2017, the IEEE published a new standard (IEEE Std
802c [IEEEStd802c]) which
[IEEEStd802c] that defines a new optional "Structured Structured Local Address Plan"
Plan (SLAP) that specifies different assignment approaches in four
specified regions of the local MAC address space. These four
regions, called SLAP quadrants, are briefly described below (see
Figure 1 and Figure 2 Table 1 for details):
o
* In SLAP Quadrant 01, "Extended Extended Local Identifier" Identifier (ELI) MAC addresses
are assigned based on a 24-bit Company ID (CID), which is assigned
by the IEEE Registration Authority (RA). The remaining bits are
specified as an extension by the CID assignee or by a protocol
designated by the CID assignee.
o
* In SLAP Quadrant 11, "Standard Standard Assigned Identifier" Identifier (SAI) MAC
addresses are assigned based on a protocol specified in an IEEE
802 standard. For 48-bit MAC addresses, 44 bits are available.
Multiple protocols for assigning SAIs may be specified in IEEE
standards. Coexistence of multiple protocols may be supported by
limiting the subspace available for assignment by each protocol.
o
* In SLAP Quadrant 00, "Administratively Administratively Assigned Identifier" 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.
o
* SLAP Quadrant 10 is "Reserved for future use" where MAC addresses
may be assigned using new methods yet to be defined, defined or until then
by an administrator 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 48-Bit MAC address structure Address Structure (in IEEE representation)
+----------+-------+-------+-----------------------+----------------+ Representation)
+==========+=======+=======+=======================+============+
| Quadrant | Y-bit | Z-bit | Local Identifier Type | Local |
| | | | | Identifier |
+----------+-------+-------+-----------------------+----------------+
+==========+=======+=======+=======================+============+
| 01 | 0 | 1 | Extended Local | ELI |
+----------+-------+-------+-----------------------+------------+
| 11 | 1 | 1 | Standard Assigned | SAI |
+----------+-------+-------+-----------------------+------------+
| 00 | 0 | 0 | Administratively | AAI |
| | | | Assigned | |
+----------+-------+-------+-----------------------+------------+
| 10 | 1 | 0 | Reserved | Reserved |
+----------+-------+-------+-----------------------+----------------+
Figure 2:
+----------+-------+-------+-----------------------+------------+
Table 1: SLAP quadrants Quadrants
1.1. Problem statement Statement
The IEEE is developing mechanisms to assign addresses (IEEE P802.1CQ
project)
[IEEE-P802.1CQ-Project]. There is also ongoing work in the
IETF [I-D.ietf-dhc-mac-assign] specifying 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, 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.
1.1.1. WiFi Wi-Fi (IEEE 802.11) devices Devices
Today, most WiFi Wi-Fi devices come with interfaces that have a "burned "burned-
in" MAC address, allocated from the universal address space using a
24-bit Organizationally Unique Identifier (OUI, assigned (OUI) (assigned to IEEE 802
interface vendors). However, recently, the need to assign local
(instead of universal) MAC addresses has emerged in particular particularly in the
following two scenarios:
o
* IoT (Internet of Things): In general, composed of constrained
devices [RFC7228] with constraints such as available power and
energy, memory, and processing resources. Examples of this
include sensors and actuators for health or home automation
applications. Given the increasingly high number of these
devices, manufacturers might prefer to equip devices with
temporary MAC addresses used only at first boot. These temporary
MAC addresses would just be used to send initial DHCP packets to
available DHCP servers. IoT devices typically need a single MAC
address for each available network interface. Once the server
assigns a MAC address, the device would abandon its temporary MAC
address. Home automation IoT devices typically do not move
(however, note that there is an increase of mobile smart health
monitoring devices, which are mobile). devices). For this type of device, in general, any
type of SLAP quadrant would be good for assigning addresses, but
ELI/SAI quadrants might be more suitable in some scenarios. For
example, the device might need to use an address from the CID
assigned to the IoT communication device vendor, thus preferring
the ELI quadrant.
o
* Privacy: Today, MAC addresses allow the exposure of users' user locations
making it relatively easy to track users' user movements. One of the
mechanisms considered to mitigate this problem is the use of local
random MAC addresses, addresses: changing them every time the user connects
to a different network. In this scenario, devices are typically
mobile. Here, AAI is probably the best SLAP quadrant from which
to assign addresses, as addresses; it is the best fit for randomization of
addresses, and it is not required for the addresses to survive
when changing networks.
1.1.2. Hypervisor: migratable vs non-migratable functions Functions That Are and Are Not Migratable
In large scale 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 to 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 data-center environments, such as the ones that are
typically used nowadays, it is expected that the data center is
divided in different network regions, each one managing its own local
address space. In this scenario, there are two possible situations
that need to be tackled:
o
* Migratable functions. 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/SAP 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 datacenter.
o Non-migratable functions. 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, that which does not need to be
unique across multiple data centers (i.e., each region can manage
its own MAC address assignment, assignment without checking for duplicates
globally).
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Where relevant, the DHCPv6 terminology from the DHCPv6 Protocol [RFC8415] also applies
here. Additionally, the following definitions are updated for this
document.
IA_LL Identity Association for Link-Layer Address: an
identity association (IA) used to request or assign
address Unless specified otherwise, a link-layer addresses. Section 10.1 of
[I-D.ietf-dhc-mac-assign] provides details on the IA_LL
option.
LLADDR Link-layer (or MAC)
address, as specified in [IEEEStd802]. The address option that is used to request
6 or
assign a 8 bytes long.
address block A number of consecutive link-layer addresses. Section 10.2 An
address block is expressed as a first address plus a
number that designates the number of [I-D.ietf-dhc-mac-assign] provides details on additional
(extra) addresses. A single address can be
represented by the
LLADDR option. 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 client, as described in [RFC8415] [RFC8415],
and supports the options (IA_LL and LLADDR) specified
in
[I-D.ietf-dhc-mac-assign], [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 delegation,
as specified in [RFC8415].
server A node that manages
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 allocation and option that is able to respond used to client queries. It implements
basic DHCP server functionality as described in
[RFC8415] and supports the options (IA_LL and LLADDR)
specified in [I-D.ietf-dhc-mac-assign], as well as the
new option (QUAD) specified in this document. The
server may request or may not support IPv6 address assignment
and prefix delegation as specified in [RFC8415].
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
functionality, as described in [RFC8415].
address Unless specified otherwise, an address means a link-
layer (or MAC) address, as specified in IEEE Std 802
[IEEEStd802]. The address is six or eight bytes long.
address block
server A number of consecutive node that manages link-layer addresses. An address block allocation and
is expressed able to respond to client queries. It implements
basic DHCP server functionality, as a first address plus a
number that designates described in
[RFC8415], and supports the number of additional (extra)
addresses. A single address can be represented by 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 itself assignment and zero extra addresses. 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
preferred SLAP quadrant using the DHCPv6 signaling procedures
described in [I-D.ietf-dhc-mac-assign]. [RFC8947]. The signaling flow is shown in Figure 3. 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 3: 2: DHCPv6 signaling flow (client-server) Signaling Flow (Client-Server)
1. Link-layer addresses (i.e., MAC addresses) are assigned in
blocks. The smallest block is a single address. To request an
assignment, the client sends a Solicit message with an IA_LL
option in the message. The IA_LL option MUST contain a an LLADDR
option. In order to indicate the preferred SLAP quadrant(s), the
IA_LL option includes the new OPTION_SLAP_QUAD option in the
IA_LL-option field (alongside the LLADDR option).
2. The server, upon receiving an IA_LL option in Solicit, 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
pool matching the requested quadrant identifier, identifier and an available
range of addresses of the requested size. If suitable addresses
are found, the server sends back an Advertise message with an
IA_LL option containing an LLADDR option that specifies the
addresses being offered. If the server manages a block of
addresses belonging to a requested quadrant, the addresses being
offered MUST belong to a requested quadrant. If the server does
not have a configured address pool matching the client's request,
it SHOULD return the IA_LL option with the addresses being
offered belonging to a quadrant managed by the server (following
a local policy to select from which of the available quadrants).
If the server has a configured address pool of the correct quadrant,
quadrant but no available addresses, it MUST return the IA_LL
option containing a Status Code option with status set to
NoAddrsAvail.
3. The client waits for available servers to send Advertise
responses and picks one server server, as defined in Section 18.2.9 of
[RFC8415]. The client SHOULD NOT pick a server that does not
advertise an address in the requested quadrant(s). The client
then sends a Request message that includes the IA_LL container
option with the LLADDR option copied from the Advertise message
sent by the chosen server. It includes the preferred SLAP
quadrant(s) in a new QUAD IA_LL-option. IA_LL option.
4. Upon reception of a Request message with an IA_LL container
option, the server assigns requested addresses. The server MAY
alter the allocation at this time (e.g., by reducing the address
block). It then generates and sends a Reply message back to the
client. Upon receiving a Reply message, the client parses the
IA_LL container option and may start using all provided
addresses. Note that a client that has included a Rapid Commit
option in the
Solicit, Solicit message may receive a Reply message in
response to the Solicit message and skip the Advertise and
Request message steps above (following standard DHCPv6
procedures).
5. The client is expected to periodically renew the link-layer
addresses
addresses, as governed by T1 and T2 timers. This mechanism can
be administratively disabled by the server sending "infinity" as
the T1 and T2 values (see Section 7.7 of [RFC8415]). The client
sends a Renew option after T1. It includes the preferred SLAP
quadrant(s) in the new QUAD IA_LL-option, IA_LL option, so in case the server
is unable to extend the lifetime on the existing address(es), the
preferred quadrants are known for the allocation of any "new"
(i.e., different) addresses.
6. The server responds with a Reply message, message with an IA_LL option
that includes an LLADDR option with extended lifetime.
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.
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
preferred SLAP quadrant using the DHCPv6 signaling procedures
described in [I-D.ietf-dhc-mac-assign]. [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 4. 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)--+ Reply(IA_LL(LLADDR))-+ |
| | |
Figure 4: 3: DHCPv6 signaling flow (client-relay-server) Signaling Flow (Client-Relay-Server)
1. Link-layer addresses (i.e., MAC addresses) are assigned in
blocks. The smallest block is a single address. To request an
assignment, the client sends a Solicit message with an IA_LL
option in the message. The IA_LL option MUST contain a an LLADDR
option.
2. The DHCP relay receives the Solicit message and encapsulates it
in a Relay-forward message. The relay, based on local knowledge
and policies, includes in the Relay-forward message the QUAD
option with the preferred quadrant. The relay might know which
quadrant to request based on local configuration (e.g., the
served network contains IoT devices only, thus requiring ELI/
SAI) or other means. Note that if a client sends multiple
instances of the IA_LL option in the same message, the DHCP
relay MAY only add a single instance of the QUAD option.
3. Upon receiving a relayed message containing an IA_LL option, the
server inspects the contents for instances of OPTION_SLAP_QUAD
in both the Relay Forward Relay-forward message and the client's message
payload. Depending on the server's policy, the instance of the
option to process is selected (see also at the end of this section).
For each of the entries in OPTION_SLAP_QUAD, in order of the
preference field (highest to lowest), the server checks if it
has a configured MAC address pool matching the requested
quadrant identifier, identifier and an available range of addresses of the
requested size. If suitable addresses are found, the server
sends back an Advertise message with an IA_LL option containing
an LLADDR option that specifies the addresses being offered.
This message is sent to the Relay in a Relay-reply message. If
the server supports the semantics of the preferred quadrant
included in the QUAD option, 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 configured to 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 one server server, as defined in Section 18.2.9 of
[RFC8415]. The client then sends a Request message that
includes the IA_LL container option with the LLADDR option
copied from the Advertise message sent by the chosen server.
6. The relay forwards the received Request in a Relay-forward
message. It adds adds, in the Relay-forward Relay-forward, a QUAD IA_LL-option IA_LL option
with the preferred quadrant.
7. Upon reception of the forwarded Request message with IA_LL
container option, the server assigns requested addresses. The
server MAY alter the allocation at this time. It then generates
and sends a Reply message, message in a Relay-reply message back to the
relay.
8. Upon receiving a Reply message, the client parses the IA_LL
container option and may start using all provided addresses.
9. The client is expected to periodically renew the link-layer
addresses
addresses, as governed by T1 and T2 timers. This mechanism can
be administratively disabled by the server sending "infinity" as
the T1 and T2 values (see Section 7.7 of [RFC8415]). The client
sends a Renew option after T1.
10. This message is forwarded by the relay in a Relay-forward
message, including a QUAD IA_LL-option IA_LL option with the preferred
quadrant.
11. The server responds with a Reply message, including an LLADDR
option with extended lifetime. This message is sent in a Relay-
reply message.
12. 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,
OPTION_SLAP_QUAD and the relay adds a second instance in its relay- Relay-
forward message. This parameter configures the server to process
either the client's, 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, use/configure and MAY decide based on that
whether to use configure use/configure the received address.
4. DHCPv6 Option Definition
4.1. Quad option QUAD Option
The QUAD option is used to specify the preferences for the selected
quadrants within an IA_LL. The option MUST either 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:
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 5: Quad 4: QUAD Option Format
option-code OPTION_SLAP_QUAD (IANA-1). (140).
option-len 2 * number of included (quadrant, preference). A 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.
A
This is a 1-byte field.
pref-n Preference associated to quadrant-n. A higher value
means a more preferred quadrant. A This is a 1-byte
field.
A quadrant identifier value MUST only appear appear, at most most, once in the
option. If an option includes more than one occurrence of the same
quadrant identifier, only the first occurence occurrence is processed 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 without with no preference value 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 provide 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, fields or if the server has a configured
address pool of the correct quadrant, 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 hence, servers MUST NOT
assume that quadrant-1/pref-1 have the highest preference (except if
there is only 1 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.
5. IANA Considerations
IANA is requested to assign has assigned the QUAD (IANA-1) (140) option code from the
DHCPv6 "Option Codes"
subregistry of the "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" registry maintained at
http://www.iana.org/assignments/dhcpv6-parameters and use the
following data when adding the option to the registry: <http://www.iana.org/assignments/
dhcpv6-parameters>:
Value: IANA-1 140
Description: OPTION_SLAP_QUAD
Client ORO: No
Singleton Option: No Yes
Reference: this document RFC 8948
6. Security Considerations
See [RFC8415] and [RFC7227] for the DHCPv6 security and privacy
considerations. See [RFC8200] for the IPv6 security considerations.
See also [I-D.ietf-dhc-mac-assign] for security considerations
regarding link-layer address assignments using DHCP.
7. 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, Eric Vyncke, Tatuya Jinmei, Carl Wallace, Ines Robles, Ted
Lemon, Jaime Jimenez, Robert Wilton, Benjamin Kaduk, Barry Leiba,
Alvaro Retana, Murray Kucherawy and Rob Wilton for their very
detailed and helpful reviews. And to Roger Marks and Antonio de la
Oliva for comments related to IEEE work Considerations
See [RFC8415] and references.
The work in document draft has been supported by [RFC7227] for the H2020 5Growth
(Grant 856709) DHCPv6 security and 5G-DIVE projects (Grant 859881).
8. privacy
considerations. See [RFC8200] for the IPv6 security considerations.
Also, see [RFC8947] for security considerations regarding link-layer
address assignments using DHCP.
7. References
8.1.
7.1. Normative References
[I-D.ietf-dhc-mac-assign]
Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer
Addresses Assignment Mechanism for DHCPv6", draft-ietf-
dhc-mac-assign-09 (work in progress), September 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of 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] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
8.2.
[RFC8947] Volz, B., Mrugalski, T., and CJ. Bernardos, "Link-Layer
Addresses Assignment Mechanism for DHCPv6", RFC 8947,
DOI 10.17487/RFC8947, November 2020,
<https://www.rfc-editor.org/info/rfc8947>.
7.2. Informative References
[IEEE-P802.1CQ-Project]
IEEE, "IEEE P802.1CQ: "P802.1CQ - Standard for Local and Metropolitan Area
Networks: Multicast and Local Address
Assignment". Assignment",
<https://standards.ieee.org/project/802_1CQ.html>.
[IEEEStd802]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture, Architecture", IEEE Std 802-2014", 802-2014,
DOI 10.1109/IEEESTD.2014.6847097, June 2014. 2014,
<https://doi.org/10.1109/IEEESTD.2014.6847097>.
[IEEEStd802c]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture, Architecture -- Amendment 2: Local
Medium Access Control (MAC) Address Usage, Usage", IEEE Std 802c-
2017", June 2017.
2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017,
<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, May 2014,
<https://www.rfc-editor.org/info/rfc7227>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A.
Sehgal, "Management of Networks with Constrained Devices:
Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015,
<https://www.rfc-editor.org/info/rfc7548>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Appendix A. Example Uses of Quadrant Selection Mechanisms examples
This appendix describes some examples of how the quadrant preference
mechanisms could be used.
Let's
First, let's take first an IoT scenario as an example. An IoT device might
decide on its own the SLAP quadrant it wants to use to obtain a local
MAC address, using the following information to take make the decision:
o
* Type of IoT deployment: e.g., 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
co-exist,
coexist, the IoT can decide to use the ELI or SAI quadrants.
o
* Mobility: if 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.
o Managed/unmanaged: depending
* Managed/Unmanaged: Depending on whether the IoT device is managed
during its lifetime or cannot be re-configured reconfigured [RFC7548], the
decision of what quadrant is more appropriate might be different.
For example, if the IoT device can be managed (e.g., configured), 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).
o Operation/battery lifetime: depending
* Operation / Battery Lifetime: Depending on the expected lifetime
of the device 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 pre-
configured
preconfigured preferences.
We now take the WiFi Wi-Fi device scenario, considering considering, for example example, that
a laptop or smartphone connects to a network using its built in 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:
o
* Type of network the device is connected: public, work, home.
o
* Trusted network: Yes/No.
o
* First time visited network: Yes/No.
o
* Network geographical location.
o
* Mobility: Yes (the device might change its network attachment
point)/No
point) / No (the device is not going to change its network
attachment point).
o
* Operating System (OS) network profile, including security/trust security/trust-
related parameters: most Most modern OSs keep metadata associated to with
the networks they can attach to, as to as, for example example, 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 or not, address, from which SLAP quadrant it should
be assigned, and how often.
o often it may be assigned.
* Triggers coming from applications regarding location privacy. privacy: An
app might request to that the OS to maximize location privacy (due to
the nature of the application) application), and this might require that the OS
forces to
force the use of a local MAC address, address or that the local MAC address is 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 that it
might change access point points several times, and therefore 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. (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, 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 data-center scenario, a hypervisor might
request local MAC addresses to be assigned to virtual machines. As in
the previous scenarios, the hypervisor might select the preferred
SLAP quadrant using information provided by the cloud management
system or virtualization infrastructure manager running on top of the
hypervisor. This information might include, but is not limited to:
o
* Migratable VM. VM: If the function implemented by the VM is subject to
be moved to another physical server or not. This 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.
o
* VM connectivity characteristics , e.g., characteristics: For example, standalone, part of
a pool, and part of a service graph/chain. If the connectivity
characteristics of the VM are known, this can be used by the
hypervisor to select the best SLAP quadrant.
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 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Alain Mourad
InterDigital Europe
Email: Alain.Mourad@InterDigital.com
URI: http://www.InterDigital.com/