SLAP quadrant selection options for DHCPv6
draft-ietf-dhc-slap-quadrant-09
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (dhc WG) | |
|---|---|---|---|
| Authors | Carlos J. Bernardos , Alain Mourad | ||
| Last updated | 2020-06-11 (Latest revision 2020-05-27) | ||
| Replaces | draft-bernardos-dhc-slap-quadrant | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Reviews |
GENART Last Call review
Ready with Issues
INTDIR Last Call review
(of
-08)
Ready with Issues
IOTDIR Last Call review
(of
-07)
Ready with Nits
|
||
| Stream | WG state | Submitted to IESG for Publication | |
| Associated WG milestone |
|
||
| Document shepherd | Ian Farrer | ||
| Shepherd write-up | Show Last changed 2020-05-12 | ||
| IESG | IESG state | IESG Evaluation::Revised I-D Needed | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Needs 3 more YES or NO OBJECTION positions to pass. |
||
| Responsible AD | Éric Vyncke | ||
| Send notices to | Tomek Mrugalski <tomasz.mrugalski@gmail.com>, Ian Farrer <ianfarrer@gmx.com> | ||
| IANA | IANA review state | IANA OK - Actions Needed | |
| IANA expert review state | Expert Reviews OK |
draft-ietf-dhc-slap-quadrant-09
DHC WG CJ. Bernardos
Internet-Draft UC3M
Intended status: Standards Track A. Mourad
Expires: November 28, 2020 InterDigital
May 27, 2020
SLAP quadrant selection options for DHCPv6
draft-ietf-dhc-slap-quadrant-09
Abstract
The IEEE originally structured the 48-bit MAC address space in such a
way that half of it was reserved for local use. Recently, the IEEE
has been working on a new specification (IEEE 802c) which defines a
new optional "Structured Local Address Plan" (SLAP) that specifies
different assignment approaches in four specified regions of the
local MAC address space.
The IEEE is working on mechanisms to allocate addresses in the one of
these quadrants (IEEE 802.1CQ). There is work also in the IETF on
specifying a new mechanism that extends DHCPv6 operation to handle
the local MAC address assignments. We complement this work by
defining a mechanism to allow choosing the SLAP quadrant to use in
the allocation of the MAC address to the requesting device/client.
This document proposes extensions to DHCPv6 protocols to enable a
DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant
to the server, so that the server allocates the MAC addresses to the
given client out of the quadrant requested by relay or client. A new
DHCPv6 option (OPTION_SLAP_QUAD, or 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 of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Bernardos & Mourad Expires November 28, 2020 [Page 1]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
This Internet-Draft will expire on November 28, 2020.
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
1.1.1. WiFi devices . . . . . . . . . . . . . . . . . . . . 4
1.1.2. Hypervisor: migratable vs non-migratable functions . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Quadrant Selection Mechanisms examples . . . . . . . . . . . 7
4. DHCPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Address Assignment from the Preferred SLAP Quadrant
Indicated by the Client . . . . . . . . . . . . . . . . . 9
4.2. Address Assignment from the SLAP Quadrant Indicated by
the Relay . . . . . . . . . . . . . . . . . . . . . . . . 11
5. DHCPv6 Options Definitions . . . . . . . . . . . . . . . . . 14
5.1. Quad (IA_LL) option . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The IEEE originally structured the 48-bit MAC address space in such a
way that half of it was reserved for local use (where the Universal/
Local -- U/L -- bit is set to 1). Recently, the IEEE has been
working on a new specification (IEEE 802c [IEEEStd802c-2017]) which
defines a new "optional Structured Local Address Plan" (SLAP) that
specifies different assignment approaches in four specified regions
Bernardos & Mourad Expires November 28, 2020 [Page 2]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
of the local MAC address space. These four regions, called SLAP
quadrants, are briefly described below (see Figure 1 and Figure 2 for
details):
o Quadrant "Extended Local Identifier" (ELI) MAC addresses are
assigned based on a Company ID (CID), which takes 24-bits, leaving
the remaining 24-bits for the locally assigned address for each
CID for unicast (M-bit = 0) and also for multicast (M-bit = 1).
The CID is assigned by the IEEE Registration Authority (RA).
o Quadrant "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. 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 Quadrant "Administratively Assigned Identifier" (AAI) MAC
addresses are assigned locally by an administrator. Multicast
IPv6 packets use a destination address starting in 33-33 and this
falls within this space and therefore should not be used to avoid
conflict with the MAC addresses used for use with IPv6 multicast
addresses. For 48-bit MAC addresses, 44 bits are available.
o Quadrant "Reserved for future use" where MAC addresses may be
assigned using new methods yet to be defined, or by an
administrator like 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)
Figure 1: IEEE 48-bit MAC address structure
Bernardos & Mourad Expires November 28, 2020 [Page 3]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
+----------+-------+-------+-----------------------+----------------+
| 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: SLAP quadrants
1.1. Problem statement
The IEEE is working on mechanisms to allocate addresses in the SAI
quadrant (IEEE 802.1CQ project). There is also ongoing work in the
IETF [I-D.ietf-dhc-mac-assign] specifying a new mechanism that
extends DHCPv6 operation to handle the local MAC address assignments.
We complement this work by defining a mechanism to allow choosing the
SLAP quadrant to use in the allocation of the MAC address to the
requesting device/client. This document proposes extensions to
DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to
indicate a preferred SLAP quadrant to the server, so that the server
allocates the MAC address to the given client out of the quadrant
requested by relay or client.
In the following, we describe two application scenarios where a need
arises to assign local MAC addresses according to preferred SLAP
quadrants.
1.1.1. WiFi devices
Today, most WiFi devices come with interfaces that have a "burned in"
MAC address, allocated from the universal address space using a
24-bit Organizationally Unique Identifier (OUI, assigned to IEEE 802
interface vendors). However, recently, the need to assign local
(instead of universal) MAC addresses has emerged in particular in the
following two scenarios:
o IoT (Internet of Things): where there are a lot of cheap,
sometimes short lived and disposable devices. Examples of this
include: sensors and actuators for health or home automation
applications. In this scenario, it is common that upon a first
boot, the device uses a temporary MAC address, to send initial
DHCP packets to available DHCP servers. IoT devices typically
request a single MAC address for each available network interface.
Once the server assigns a MAC address, the device abandons its
Bernardos & Mourad Expires November 28, 2020 [Page 4]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
temporary MAC address. This type of device is typically not
moving. In general, any type of SLAP quadrant would be good for
assigning addresses from, but ELI/SAI quadrants might be more
suitable in some scenarios, such as if the addresses need to
belong to the CID assigned to the IoT communication device vendor.
o Privacy: Today, MAC addresses allow the exposure of users'
locations making it relatively easy to track users' movement. One
of the mechanisms considered to mitigate this problem is the use
of local random MAC 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 to
assign addresses from, as 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
In large scale virtualization environments, thousands of virtual
machines (VMs) are active. These VMs are typically managed by a
hypervisor, 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 available DHCP servers to assign
one or more MAC addresses (an address block). The hypervisor does
not use those addresses for itself, but rather uses them to create
new VMs with appropriate MAC addresses. If we assume very large data
center environments, such as the ones that are typically used
nowadays, it is expected that the data center is divided in different
network regions, each one managing its own local address space. In
this scenario, there are two possible situations that need to be
tackled:
o Migratable functions. If a VM (providing a given function) needs
to be migrated to another region of the data center (e.g., for
maintenance, resilience, end-user mobility, etc.), the VM's
networking context needs to migrate with the VM. This includes
the VM's MAC address(es). Therefore, for this case, it is better
to allocate addresses from the ELI/SAI SLAP quadrant, which can be
centrally allocated by the DHCP server.
o Non-migratable functions. 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 more
efficient to allocate it from the AAI SLAP quadrant, that does not
need to be unique across multiple data centers (i.e., each region
can manage its own MAC address assignment, without checking for
duplicates globally).
Bernardos & Mourad Expires November 28, 2020 [Page 5]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
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.
client A device that is interested in obtaining link-layer
addresses. It implements the basic DHCPv6 mechanisms
needed by a DHCPv6 client as described in [RFC8415] and
supports the new options (IA_LL and LLADDR) specified
in [I-D.ietf-dhc-mac-assign]. The client may or may
not support address assignment and prefix delegation as
specified in [RFC8415].
server Software that manages link-layer address allocation and
is able to respond to client queries. It implements
basic DHCPv6 server functionality as described in
[RFC8415] and supports the new options (IA_LL and
LLADDR) specified in [I-D.ietf-dhc-mac-assign]. The
server may or may not support address assignment and
prefix delegation as specified in [RFC8415].
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].
address Unless specified otherwise, an address means a link-
layer (or MAC) address, as defined in IEEE802. The
address is typically 6 bytes long, but some network
architectures may use different lengths.
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.
Bernardos & Mourad Expires November 28, 2020 [Page 6]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
3. Quadrant Selection Mechanisms examples
The following section describes some examples of how the quadrant
preference mechanisms could be used.
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 the decision:
o Type of IoT deployment: e.g., industrial, domestic, rural, etc.
For small deployments, such as domestic ones, the IoT 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, the IoT can decide to use the ELI or SAI quadrants.
o Mobility: if the IoT device can move, then it might prefer to
select the SAI or AAI quadrants to minimize address collisions
when moving to another network. If the device is known to remain
fixed, then the ELI is probably the most suitable one to use.
o Managed/unmanaged: depending on whether the IoT device is managed
during its lifetime or cannot be re-configured, the selected
quadrant might be different. For example, if it can be managed,
this means that network topology changes might occur during its
lifetime (e.g., due to changes on the deployment, such as
extensions involving additional devices), and this might have an
impact on the preferred quadrant (e.g., to avoid potential
collisions in the future).
o 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 simple decision making process based on pre-
configured preferences.
If we now take the WiFi device scenario, considering for example that
a laptop or smartphone connects to a network using its built in MAC
address. Due to privacy/security concerns, the device might want to
configure a local MAC address. The device might use different
parameters and context information to decide, not only which SLAP
quadrant to use for the local MAC address configuration, but also
Bernardos & Mourad Expires November 28, 2020 [Page 7]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
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? Y/N.
o First time visited network? Y/N.
o Network geographical location.
o Mobility? Y/N.
o Operating System (OS) network profile, including security/trust
related parameters. Most modern OSs keep metadata associated to
the networks they can attach to, as for 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 to configure a
local MAC address or not, from which SLAP quadrant and how often.
o Triggers coming from applications regarding location privacy. An
app might request to the OS to maximize location privacy (due to
the nature of the application) and this might require that the OS
forces the use of a local MAC address, or that the local MAC
address is 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 several times, and therefore it is best to
minimize the chances of address collision, using the SAI or AAI
quadrants. If the device is not moving and attached to a trusted
network (e.g. 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 used might also be used as an additional
enhancement to make it harder to track the user location.
Last, if we consider the data center scenario, a hypervisor might
request local MAC addresses 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
Bernardos & Mourad Expires November 28, 2020 [Page 8]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
system (CMS) or virtualization infrastructure manager (VIM) running
on top of the hypervisor. This information might include, but is not
limited to:
o Migratable VM. If the function implemented by the VM is subject
to be moved to another physical server or not. This has an impact
on the preference for the SLAP quadrant, as some quadrants are
better suited (e.g., ELI/SAI) for supporting migration in a large
data center.
o VM connectivity characteristics , e.g.,: standalone, part of a
pool, 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.
4. DHCPv6 Extensions
4.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]. The signaling flow is shown
in Figure 3.
+--------+ +--------+
| DHCPv6 | | DHCPv6 |
| client | | server |
+--------+ +--------+
| |
+-------1. Solicit(IA_LL(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: DHCPv6 signaling flow (client-server)
Bernardos & Mourad Expires November 28, 2020 [Page 9]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
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 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 (with the LLAADR option).
2. The server, upon receiving an IA_LL option, inspects its
contents. 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, 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 supports the new QUAD IA_LL-option, and manages a
block of addresses belonging to the requested quadrant(s), the
addresses being offered MUST belong to the requested quadrant(s).
If the server does not have a configured address pool matching
the client's request, it MUST return the IA_LL option containing
a Status Code option with status set to NoQuadAvail (IANA-2). If
the client specified more than one SLAP quadrant, the server MUST
only return a NoQuadAvail status code if no address pool(s)
configured at the server match any of the specified SLAP
quadrants. 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 Code option with status set to
NoAddrsAvail.
3. The client waits for available servers to send Advertise
responses and picks one 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. 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
the new QUAD IA_LL-option.
4. Upon reception of a 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 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, may receive a Reply in response to
the Solicit and skip the Advertise and Request steps above
(following standard DHCPv6 procedures).
Bernardos & Mourad Expires November 28, 2020 [Page 10]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
5. The client is expected to periodically renew the link-layer
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]). When the
assigned addresses are about to expire, the client sends a Renew
message. It includes the preferred SLAP quadrant(s) in the new
QUAD 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, including an LLADDR
option with extended lifetime.
The client SHOULD check if the received MAC address comes from one of
the requested quadrants. Otherwise, the client SHOULD NOT configure
the obtained address. It MAY repeat the process selecting a
different DHCP server.
4.2. Address Assignment from the 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]. 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.
Bernardos & Mourad Expires November 28, 2020 [Page 11]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
+--------+ +--------+ +--------+
| 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 4: DHCPv6 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 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
Bernardos & Mourad Expires November 28, 2020 [Page 12]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
instances of the IA_LL option in the same message, the DHCP
relay MUST 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 message and the client's message
payload. Depending on the server's policy, the instance(s) of
the option to process is selected. 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, 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, and
manages a block of addresses belonging to the requested
quadrant(s), then the addresses being offered MUST belong to the
requested quadrant(s). 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 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 in the Relay-forward a QUAD 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, in a Relay-reply 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 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]). When the
Bernardos & Mourad Expires November 28, 2020 [Page 13]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
assigned addresses are about to expire, the client sends a Renew
message.
10. This message is 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, 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, and the relay adds a second instance in its relay-
forward message. This parameter configures the server to process
either the client's, or the relay's instance of option QUAD. It is
RECOMMENDED that the default for such a parameter is to process the
client's instance of the option.
The client MAY check if the received MAC address belongs to a
quadrant it is willing to use/configure, and MAY decide based on that
whether to use configure the received address.
5. DHCPv6 Options Definitions
5.1. Quad (IA_LL) option
The QUAD option is used to specify the preferences for the selected
quadrants within an IA_LL. The option MUST either be encapsulated 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Quad Option Format
Bernardos & Mourad Expires November 28, 2020 [Page 14]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
option-code OPTION_SLAP_QUAD (IANA-1).
option-len 2 * number of included (quadrant, preference). 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, 3: SAI). Each quadrant MUST only appear
once at most in the option. A 1-byte field.
pref-n Preference associated to quadrant-n. A higher value
means a more preferred quadrant. 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 occurence 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 a quadrant - preference tuple is
used in this option (instead of using a list of quadrants ordered by
preference) to 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 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 cannot provide an assignment from one of the specified
quadrant-n fields, it MUST NOT assign any addresses and return a
status of NoQuadAvail (IANA-2) in the IA_LL Option.
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 1 set of values).
6. IANA Considerations
IANA is requested to assign the QUAD (IANA-1) option code from the
DHCPv6 "Option Codes" registry maintained at
http://www.iana.org/assignments/dhcpv6-parameters and use the
following data when adding the option to the registry:
Bernardos & Mourad Expires November 28, 2020 [Page 15]
Internet-Draft DHCPv6 SLAP quadrant selection May 2020
Value: IANA-1
Description: OPTION_SLAP_QUAD
Client ORO: No
Singleton Option: No
Reference: this document
IANA is requested to assign the NoQuadAvail (IANA-2) code from the
DHCPv6 "Status Codes" registry maintained
athttp://www.iana.org/assignments/dhcpv6-parameters and use the
following data when adding the option to the registry:
Value: IANA-2
Description: NoQuadAvail
Reference: this document
7. Security Considerations
See [RFC8415] for the DHCPv6 security 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.
8. 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 and Carl Wallace for their very
detailed and helpful reviews.
The work in this draft will be further developed and explored under
the framework of the H2020 5Growth (Grant 856709) and 5G-DIVE
projects (Grant 859881).
9. References
9.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-06 (work in progress), May 2020.
Bernardos & Mourad Expires November 28, 2020 [Page 16]
Internet-Draft DHCPv6 SLAP quadrant selection May 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>.
[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>.
[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>.
9.2. Informative References
[IEEEStd802c-2017]
IEEE Computer Society, "IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture,
Amendment 2: Local Medium Access Control (MAC) Address
Usage, IEEE Std 802c-2017".
Authors' Addresses
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
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/
Bernardos & Mourad Expires November 28, 2020 [Page 17]