rfc8948xml2.original.xml   rfc8948.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-ietf-dhc-slap-quadrant-12" number="8948" ipr="trust200902"
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc obsoletes="" updates="" submissionType="IETF" category="std"
e.RFC.2119.xml'> consensus="true" xml:lang="en" tocInclude="true" tocDepth="3"
<!ENTITY rfc8174 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc symRefs="true" sortRefs="true" version="3">
e.RFC.8174.xml'>
<!ENTITY rfc8415 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.8415.xml'>
<!ENTITY I-D.ietf-dhc-mac-assign SYSTEM 'http://xml.resource.org/public/rfc/bi
bxml3/reference.I-D.ietf-dhc-mac-assign.xml'>
<!ENTITY rfc8200 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.8200.xml'>
<!ENTITY rfc7228 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.7228.xml'>
<!ENTITY rfc7548 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.7548.xml'>
<!ENTITY rfc7227 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.7227.xml'>
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-dhc-slap-quadrant-12" <!-- xml2rfc v2v3 conversion 3.2.1 -->
ipr="trust200902">
<front> <front>
<title abbrev="DHCPv6 SLAP quadrant selection">
SLAP quadrant selection option for DHCPv6
</title>
<!-- AUTHORS --> <title abbrev="DHCPv6 SLAP Quadrant Selection">
<author fullname="Carlos J. Bernardos" Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6
initials="CJ." </title>
surname="Bernardos"> <seriesInfo name="RFC" value="8948"/>
<author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos">
<organization abbrev="UC3M"> <organization abbrev="UC3M">
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
</organization> </organization>
<address> <address>
<postal> <postal>
<street>Av. Universidad, 30</street> <street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city> <city>Leganes, Madrid</city>
<code>28911</code> <code>28911</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone>+34 91624 6236</phone> <phone>+34 91624 6236</phone>
<email>cjbc@it.uc3m.es</email> <email>cjbc@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/cjbc/</uri> <uri>http://www.it.uc3m.es/cjbc/</uri>
</address> </address>
</author> </author>
<author fullname="Alain Mourad" initials="A." surname="Mourad">
<author fullname="Alain Mourad"
initials="A."
surname="Mourad">
<organization abbrev="InterDigital"> <organization abbrev="InterDigital">
InterDigital Europe InterDigital Europe
</organization> </organization>
<address> <address>
<email>Alain.Mourad@InterDigital.com</email> <email>Alain.Mourad@InterDigital.com</email>
<uri>http://www.InterDigital.com/</uri> <uri>http://www.InterDigital.com/</uri>
</address> </address>
</author> </author>
<date month="November" year="2020"/>
<date month="October" year="2020" />
<area>Internet</area> <area>Internet</area>
<workgroup>DHC WG</workgroup> <workgroup>DHC WG</workgroup>
<abstract> <abstract>
<t> <t>
IEEE originally structured the 48-bit MAC address space in such a way that half The IEEE originally structured the 48-bit Media Access Control (MAC) address spa
of it was reserved for local use. In 2017, IEEE published a new standard (IEEE ce in such a way that half
Std 802c) with a new optional "Structured Local Address Plan" (SLAP). It of it was reserved for local use. In 2017, the IEEE published a new standard (IE
EE
Std 802c) with a new optional Structured Local Address Plan (SLAP). It
specifies different assignment approaches in four specified regions of the local specifies different assignment approaches in four specified regions of the local
MAC address space. MAC address space.
</t> </t>
<t> <t>
IEEE is developing protocols to assign addresses (IEEE P802.1CQ). There is work The IEEE is developing protocols to assign addresses (IEEE
also in the IETF on specifying a new mechanism that extends DHCPv6 operation to P802.1CQ). There is also work
in the IETF on specifying a new mechanism that extends DHCPv6 operation to
handle the local MAC address assignments. handle the local MAC address assignments.
</t> </t>
<t> <t>
This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 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 or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that
the server may allocate MAC addresses in the quadrant requested by the relay or 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. client. A new DHCPv6 option (QUAD) is defined for this purpose.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sec_introduction" numbered="true" toc="default">
<section anchor="sec:introduction" title="Introduction"> <name>Introduction</name>
<t>The IEEE structures the 48-bit MAC address space in such a way that hal
<t> f of it is
IEEE structures 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). In
reserved for local use (where the Universal/Local -- U/L -- bit is set to 1). In 2017, the IEEE published a new standard <xref target="IEEEStd802c" format="defau
2017, IEEE published a new standard (IEEE Std 802c <xref target="IEEEStd802c"/>) lt"/>
which defines a new optional "Structured Local Address Plan" (SLAP) that that defines a new optional Structured Local Address Plan (SLAP) that
specifies different assignment approaches in four specified regions of the local specifies different assignment approaches in four specified regions of the local
MAC address space. These four regions, called SLAP quadrants, are briefly MAC address space. These four regions, called SLAP quadrants, are briefly
described below (see <xref target="fig:ieee_48bit_mac" /> and <xref described below (see <xref target="fig_ieee_48bit_mac" format="default"/> and <x
target="fig:slap_quadrants" /> for details): ref target="fig_slap_quadrants" format="default"/> for details):
<list style="symbols">
<t> </t>
In SLAP Quadrant 01, “Extended Local Identifier” (ELI) MAC addresses are <ul spacing="normal">
assigned based on a 24-bit Company ID (CID), assigned by the IEEE Registration <li>
In SLAP Quadrant 01, Extended Local Identifier (ELI) MAC addresses are
assigned based on a 24-bit Company ID (CID), which is assigned by the IEEE Regis
tration
Authority (RA). The remaining bits are specified as an extension by the CID Authority (RA). The remaining bits are specified as an extension by the CID
assignee or by a protocol designated by the CID assignee. assignee or by a protocol designated by the CID assignee.
</t> </li>
<li>
<t> In SLAP Quadrant 11, Standard Assigned Identifier (SAI) MAC addresses are
In SLAP Quadrant 11, “Standard Assigned Identifier” (SAI) MAC addresses are
assigned based on a protocol specified in an IEEE 802 standard. For 48-bit MAC 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 addresses, 44 bits are available. Multiple protocols for assigning SAIs may be
specified in IEEE standards. Coexistence of multiple protocols may be supported specified in IEEE standards. Coexistence of multiple protocols may be supported
by limiting the subspace available for assignment by each protocol. by limiting the subspace available for assignment by each protocol.
</t> </li>
<li>
<t> In SLAP Quadrant 00, Administratively Assigned Identifier (AAI) MAC addresses
In SLAP Quadrant 00, “Administratively Assigned Identifier” (AAI) MAC addresses
are assigned locally by an administrator. Multicast IPv6 packets use a 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 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. be assigned. For 48-bit MAC addresses, 44 bits are available.
</t> </li>
<li>
<t> SLAP Quadrant 10 is "Reserved for future use" where MAC addresses may be
SLAP Quadrant 10 is “Reserved for future use” where MAC addresses may be assigned using new methods yet to be defined or until then by an administrator
assigned using new methods yet to be defined, or until then by an administrator
as in the AAI quadrant. For 48-bit MAC addresses, 44 bits would be available. as in the AAI quadrant. For 48-bit MAC addresses, 44 bits would be available.
</t> </li>
</ul>
</list> <figure anchor="fig_ieee_48bit_mac">
<name>IEEE 48-Bit MAC Address Structure (in IEEE Representation)</name>
</t>
<figure anchor="fig:ieee_48bit_mac" title="IEEE 48-bit MAC address structure (in <artwork><![CDATA[
IEEE representation)" >
<artwork><![CDATA[
LSB MSB LSB MSB
M X Y Z - - - - M X Y Z - - - -
| | | | | | | |
| | | +------------ SLAP Z-bit | | | +------------ SLAP Z-bit
| | +--------------- SLAP Y-bit | | +--------------- SLAP Y-bit
| +------------------ X-bit (U/L) = 1 for locally assigned | +------------------ X-bit (U/L) = 1 for locally assigned
+--------------------- M-bit (I/G) (unicast/group) +--------------------- M-bit (I/G) (unicast/group)
]]></artwork>
</figure>
<figure anchor="fig:slap_quadrants" title="SLAP quadrants" > Legend:
<artwork><![CDATA[ LSB: Least Significant Bit
+----------+-------+-------+-----------------------+----------------+ MSB: Most Significant Bit
| Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | ]]></artwork>
| | | | | Identifier |
+----------+-------+-------+-----------------------+----------------+
| 01 | 0 | 1 | Extended Local | ELI |
| 11 | 1 | 1 | Standard Assigned | SAI |
| 00 | 0 | 0 | Administratively | AAI |
| | | | Assigned | |
| 10 | 1 | 0 | Reserved | Reserved |
+----------+-------+-------+-----------------------+----------------+
]]></artwork>
</figure>
<section anchor="sec:ps" title="Problem statement"> </figure>
<table anchor="fig_slap_quadrants">
<name>SLAP Quadrants</name>
<thead>
<tr>
<th>Quadrant</th>
<th>Y-bit</th>
<th>Z-bit</th>
<th>Local Identifier Type</th>
<th>Local Identifier</th>
</tr>
</thead>
<tbody>
<tr>
<td>01</td>
<td>0</td>
<td>1</td>
<td>Extended Local</td>
<td>ELI</td>
</tr>
<tr>
<td>11</td>
<td>1</td>
<td>1</td>
<td>Standard Assigned</td>
<td>SAI</td>
</tr>
<tr>
<td>00</td>
<td>0</td>
<td>0</td>
<td>Administratively Assigned</td>
<td>AAI</td>
</tr>
<tr>
<td>10</td>
<td>1</td>
<td>0</td>
<td>Reserved</td>
<td>Reserved</td>
</tr>
</tbody>
</table>
<section anchor="sec_ps" numbered="true" toc="default">
<name>Problem Statement</name>
<t> <t>
IEEE is developing mechanisms to assign addresses (IEEE P802.1CQ project) <xref
target="IEEE-P802.1CQ-Project" />. There The IEEE is developing mechanisms to assign addresses <xref
is also ongoing work in the IETF <xref target="I-D.ietf-dhc-mac-assign" /> target="IEEE-P802.1CQ-Project" format="default"/>. And <xref target="RFC8947"
specifying a new mechanism that extends DHCPv6 operation to handle the local MAC format="default"/> specifies a new mechanism that extends DHCPv6 operation to ha
address assignments. This document proposes extensions to DHCPv6 protocols to ndle 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 enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant
to the server, so that the server may allocate the MAC addresses in the quadrant to the server so that the server may allocate the MAC addresses in the quadrant
requested by the relay or client. requested by the relay or client.
</t> </t>
<t> <t>
In the following, we describe two application scenarios in which a need arises In the following, we describe two application scenarios in which a need arises
to assign local MAC addresses according to preferred SLAP quadrants. to assign local MAC addresses according to preferred SLAP quadrants.
</t> </t>
<section anchor="sec_wifi_devices" numbered="true" toc="default">
<section anchor="sec:wifi_devices" title="WiFi (IEEE 802.11) devices"> <name>Wi-Fi (IEEE 802.11) Devices</name>
<t> <t>
Today, most WiFi devices come with interfaces that have a “burned in” MAC Today, most Wi-Fi devices come with interfaces that have a "burned-in" MAC
address, allocated from the universal address space using a 24-bit address, allocated from the universal address space using a 24-bit
Organizationally Unique Identifier (OUI, assigned to IEEE 802 interface Organizationally Unique Identifier (OUI) (assigned to IEEE 802 interface
vendors). However, recently, the need to assign local (instead of universal) MAC vendors). However, recently, the need to assign local (instead of universal) MAC
addresses has emerged in particular in the following two scenarios: addresses has emerged particularly in the following two scenarios:
</t>
<list style="symbols"> <ul spacing="normal">
<li>
<t>
IoT (Internet of Things): In general, composed of constrained devices <xref IoT (Internet of Things): In general, composed of constrained devices <xref
target="RFC7228" /> with constraints such as available power and energy, memory, target="RFC7228" format="default"/> with constraints such as available power
and energy, memory,
and processing resources. Examples of this include sensors and actuators for and processing resources. Examples of this include sensors and actuators for
health or home automation applications. Given the increasingly high number of health or home automation applications. Given the increasingly high number of
these devices, manufacturers might prefer to equip devices with temporary MAC these devices, manufacturers might prefer to equip devices with temporary MAC
addresses used only at first boot. These temporary MAC addresses would just be 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 used to send initial DHCP packets to available DHCP servers. IoT devices
typically need a single MAC address for each available network interface. Once 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 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 address. Home automation IoT devices typically do not move (however, note that
there is an increase of smart health monitoring devices, which are mobile). For there is an increase of mobile smart health monitoring devices). For
this type of device, in general, any type of SLAP quadrant would be good 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 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 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 assigned to the IoT communication&nbsp;device vendor, thus preferring the ELI
quadrant. quadrant.
</t> </li>
<li>
<t> Privacy: Today, MAC addresses allow the exposure of user locations making it
Privacy: Today, MAC addresses allow the exposure of users’ locations making it relatively easy to track user movements. One of the mechanisms considered to
relatively easy to track users’ movements. One of the mechanisms considered to mitigate this problem is the use of local random MAC addresses: changing them
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 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 are typically mobile. Here, AAI is probably the best SLAP quadrant from which to
assign addresses, as it is the best fit for randomization of addresses, and it i s assign addresses; it is the best fit for randomization of addresses, and it is
not required for the addresses to survive when changing networks. not required for the addresses to survive when changing networks.
</t> </li>
</ul>
</list>
</t>
</section> </section>
<section anchor="sec_hypervisors" numbered="true" toc="default">
<section anchor="sec:hypervisors" title="Hypervisor: migratable vs non-m <name>Hypervisor: Functions That Are and Are Not Migratable</name>
igratable functions">
<t> <t>
In large scale virtualization environments, thousands of virtual machines (VMs) In large-scale virtualization environments, thousands of virtual machines (VMs)
are active. These VMs are typically managed by a hypervisor, in charge of 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 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 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 that, the hypervisor acts as a DHCP client and requests that available DHCP serv
to assign one or more MAC addresses (an address block). The hypervisor does not ers
use those addresses for itself, but rather uses them to create new VMs with assign one or more MAC addresses (an address block). The hypervisor does not
appropriate MAC addresses. If we assume very large data center environments, use those addresses for itself, but rather it uses them to create new VMs with
appropriate MAC addresses. If we assume very large data-center environments,
such as the ones that are typically used nowadays, it is expected that the data 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 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 address space. In this scenario, there are two possible situations that need to
be tackled: be tackled:
<list style="symbols"> </t>
<ul spacing="normal">
<t> <li>Migratable functions: If a VM (providing a given function) needs to be migra
Migratable functions. If a VM (providing a given function) needs to be migrated ted
to another region of the data center (e.g., for maintenance, resilience, 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 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 VM. This includes the VM's MAC address(es). Since the assignments from the
ELI/SAP SLAP quadrants are governed by rules per IEEE Std 802c, they are more 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. appropriate for use to ensure MAC address uniqueness globally in the data center
</t> .
</li>
<t> <li>Functions that are not migratable: If a VM will not be migrated to another r
Non-migratable functions.  If a VM will not be migrated to another region of the egion of the
data center, there are no requirements associated with its MAC address. In this 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 does case, it is simpler to allocate it from the AAI SLAP quadrant, which does
not need to be unique across multiple data centers (i.e., each region can not need to be unique across multiple data centers (i.e., each region can
manage its own MAC address assignment, without checking for duplicates manage its own MAC address assignment without checking for duplicates
globally). globally).
</t> </li>
</ul>
</list>
</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec_terminology" numbered="true" toc="default">
<section anchor="sec:terminology" title="Terminology"> <name>Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this </bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</b
document are to be interpreted as described in BCP 14 <xref target="RFC2119" /> cp14>",
<xref target="RFC8174" /> when, and only when, they appear in all capitals, as "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMEND
ED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119" for
mat="default"/>
<xref target="RFC8174" format="default"/> when, and only when, they appe
ar in all capitals, as
shown here. shown here.
</t> </t>
<t> <t>
Where relevant, the DHCPv6 terminology from the DHCPv6 Protocol <xref Where relevant, the DHCPv6 terminology from <xref target="RFC8415" format="defau
target="RFC8415"/> also applies here. Additionally, the following definitions lt"/> also applies here. Additionally, the following definitions
are updated for this document. are updated for this document.
</t> </t>
<t> <dl newline="false" spacing="normal" indent="15">
<list hangIndent="14" style="hanging"> <dt>address</dt>
<dd>Unless specified otherwise, a
<t hangText="IA_LL">Identity Association for Link-Layer Address: an link-layer (or MAC) address, as specified in
identity association (IA) used to request or assign <xref target="IEEEStd802" format="default"/>. The address is 6 or 8 by
link-layer addresses. Section 10.1 of tes long.</dd>
<xref target="I-D.ietf-dhc-mac-assign" /> provides details on <dt>address block</dt>
the IA_LL option.</t> <dd>A number of consecutive link-layer
addresses. An address block is expressed as a first address
<t hangText="LLADDR">Link-layer address option that is used to request plus a number that designates the number of additional (extra) address
or es.
assign a block of link-layer addresses. Section 10.2 of A single address can be represented by the address itself and zero
<xref target="I-D.ietf-dhc-mac-assign" /> provides details on the LLAD extra addresses.</dd>
DR <dt>client</dt>
option.</t> <dd>A node that is interested in obtaining link-layer
<t hangText="client">A node that is interested in obtaining link-layer
addresses. It implements the basic DHCP mechanisms needed by a DHCP addresses. It implements the basic DHCP mechanisms needed by a DHCP
client as described in <xref target="RFC8415"/> and supports the optio client, as described in <xref target="RFC8415" format="default"/>, and
ns supports the options
(IA_LL and LLADDR) specified in <xref target="I-D.ietf-dhc-mac-assign" (IA_LL and LLADDR) specified in <xref target="RFC8947" format="default
/>, "/>
as well as the new option (QUAD) specified in this document. The clien t as well as the new option (QUAD) specified in this document. The clien t
may or may not support IPv6 address assignment and prefix delegation a may or may not support IPv6 address assignment and prefix delegation,
s as
specified in <xref target="RFC8415"/>.</t> specified in <xref target="RFC8415" format="default"/>.</dd>
<dt>IA_LL</dt>
<t hangText="server">A node that manages link-layer address allocation <dd>Identity Association for Link-Layer Address, an
and identity association (IA) used to request or assign
is able to respond to client queries. It implements basic DHCP link-layer addresses.
server functionality as described in <xref target="RFC8415"/> and <xref target="RFC8947" section="11.1" sectionFormat="of"/> provides de
supports the options (IA_LL and LLADDR) specified in tails on
<xref target="I-D.ietf-dhc-mac-assign" />, as well as the new option the IA_LL option.</dd>
(QUAD) specified in this document. The server may or may not support <dt>LLADDR</dt>
IPv6 address assignment and prefix delegation as specified in <dd>Link-layer address option that is used to request or
<xref target="RFC8415"/>.</t> assign a block of link-layer addresses.
<xref target="RFC8947" section="11.2" sectionFormat="of"/> provides de
<t hangText="relay"> A node that acts as an intermediary to deliver tails on the LLADDR
option.</dd>
<dt>relay</dt>
<dd> A node that acts as an intermediary to deliver
DHCP messages between clients and servers. A relay, based on local DHCP messages between clients and servers. A relay, based on local
knowledge and policies, may include the preferred SLAP quadrant in a Q UAD knowledge and policies, may include the preferred SLAP quadrant in a Q UAD
option sent to the server. The relay implements basic DHCPv6 relay age nt option sent to the server. The relay implements basic DHCPv6 relay age nt
functionality as described in <xref target="RFC8415"/>.</t> functionality, as described in <xref target="RFC8415" format="default"
/>.</dd>
<t hangText="address">Unless specified otherwise, an address means a <dt>server</dt>
link-layer (or MAC) address, as specified in IEEE Std 802 <dd>A node that manages link-layer address allocation and
<xref target="IEEEStd802" />. The address is six or eight bytes long.< is able to respond to client queries. It implements basic DHCP
/t> server functionality, as described in <xref target="RFC8415" format="d
efault"/>, and
<t hangText="address block">A number of consecutive link-layer supports the options (IA_LL and LLADDR) specified in
addresses. An address block is expressed as a first address <xref target="RFC8947" format="default"/> as well as the new option
plus a number that designates the number of additional (extra) address (QUAD) specified in this document. The server may or may not support
es. IPv6 address assignment and prefix delegation, as specified in
A single address can be represented by the address itself and zero <xref target="RFC8415" format="default"/>.</dd>
extra addresses.</t> </dl>
</list>
</t>
</section> </section>
<section anchor="sec_dhcpv6_extensions" numbered="true" toc="default">
<section anchor="sec:dhcpv6_extensions" title="DHCPv6 Extensions"> <name>DHCPv6 Extensions</name>
<section anchor="sec_dhcpv6_ext_client" numbered="true" toc="default">
<section anchor="sec:dhcpv6_ext_client" title="Address Assignment from the <name>Address Assignment from the Preferred SLAP Quadrant Indicated by t
Preferred SLAP Quadrant Indicated by the Client"> he Client</name>
<t> <t>
Next, we describe the protocol operations for a client to select a preferred Next, we describe the protocol operations for a client to select a preferred
SLAP quadrant using the DHCPv6 signaling procedures described in <xref SLAP quadrant using the DHCPv6 signaling procedures described in <xref target="R
target="I-D.ietf-dhc-mac-assign" />. The signaling flow is shown in <xref FC8947" format="default"/>. The signaling flow is shown in <xref target="fig_dhc
target="fig:dhcpv6_flow_client" />. pv6_flow_client" format="default"/>.
</t> </t>
<figure anchor="fig:dhcpv6_flow_client" title="DHCPv6 signaling flow (client-ser <figure anchor="fig_dhcpv6_flow_client">
ver)" > <name>DHCPv6 Signaling Flow (Client-Server)</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+
| DHCPv6 | | DHCPv6 | | DHCPv6 | | DHCPv6 |
| client | | server | | client | | server |
+--------+ +--------+ +--------+ +--------+
| | | |
+----1. Solicit(IA_LL(LLADDR,QUAD))--->| +----1. Solicit(IA_LL(LLADDR,QUAD))--->|
| | | |
|<--2. Advertise(IA_LL(LLADDR,QUAD))---+ |<--2. Advertise(IA_LL(LLADDR,QUAD))---+
| | | |
+---3. Request(IA_LL(LLADDR,QUAD))---->| +---3. Request(IA_LL(LLADDR,QUAD))---->|
| | | |
|<------4. Reply(IA_LL(LLADDR))--------+ |<------4. Reply(IA_LL(LLADDR))--------+
| | | |
· · . .
· (timer expiring) · . (timer expiring) .
· · . .
| | | |
+---5. Renew(IA_LL(LLADDR,QUAD))------>| +---5. Renew(IA_LL(LLADDR,QUAD))------>|
| | | |
|<-----6. Reply(IA_LL(LLADDR))---------+ |<-----6. Reply(IA_LL(LLADDR))---------+
| | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<ol spacing="normal" type="1"><li>
<t>
<list style="numbers">
<t>
Link-layer addresses (i.e., MAC addresses) are assigned in blocks. The smallest 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 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 message with an IA_LL option in the message. The IA_LL option <bcp14>MUST</bcp14 > contain an
LLADDR option. In order to indicate the preferred SLAP quadrant(s), the IA_LL 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 (along side the option includes the new OPTION_SLAP_QUAD option in the IA_LL-option field (along side the
LLADDR option). LLADDR option).
</t> </li>
<li>
<t> The server, upon receiving an IA_LL option in a Solicit message, inspects its co
The server, upon receiving an IA_LL option in Solicit, inspects its contents. ntents.
For each of the entries in OPTION_SLAP_QUAD, in order of the preference field For each of the entries in the OPTION_SLAP_QUAD, in order of the preference fiel
d
(highest to lowest), the server checks if it has a configured MAC address pool (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 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 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 Advertise message with an IA_LL option containing an LLADDR option that
specifies the addresses being offered. If the server manages a block of specifies the addresses being offered. If the server manages a block of
addresses belonging to a requested quadrant, the addresses being offered MUST addresses belonging to a requested quadrant, the addresses being offered <bcp14> MUST</bcp14>
belong to a requested quadrant. If the server does not have a configured address 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 pool matching the client's request, it <bcp14>SHOULD</bcp14> return the IA_LL op tion with the
addresses being offered belonging to a quadrant managed by the server (following 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 a local policy to select from which of the available quadrants). If the server
has a configured address pool of the correct quadrant, but no available 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 addresses, it <bcp14>MUST</bcp14> return the IA_LL option containing a Status Co
de option with
status set to NoAddrsAvail. status set to NoAddrsAvail.
</t> </li>
<li>
<t>
The client waits for available servers to send Advertise responses and picks one The client waits for available servers to send Advertise responses and picks one
server as defined in Section 18.2.9 of <xref target="RFC8415" />. The client server, as defined in <xref target="RFC8415" section="18.2.9" sectionFormat="of"
SHOULD NOT pick a server that does not advertise an address in the requested />. The client
<bcp14>SHOULD NOT</bcp14> pick a server that does not advertise an address in th
e requested
quadrant(s). The client then sends a Request message that includes the IA_LL 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 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 by the chosen server. It includes the preferred SLAP quadrant(s) in a new QUAD
IA_LL-option. IA_LL option.
</t> </li>
<li>
<t> Upon reception of a Request message with an IA_LL container option, the server
Upon reception of a Request message with IA_LL container option, the server assigns requested addresses. The server <bcp14>MAY</bcp14> alter the allocation
assigns requested addresses. The server MAY alter the allocation at this time at this time
(e.g., by reducing the address block). It then generates and sends a Reply (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 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 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 a client that has included a Rapid Commit option in the Solicit
Reply in response to the Solicit and skip the Advertise and Request steps above 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). (following standard DHCPv6 procedures).
</t> </li>
<li>
<t> The client is expected to periodically renew the link-layer addresses, as
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 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 <xref the server sending "infinity" as the T1 and T2 values (see <xref target="RFC8415
target="RFC8415" />). The client sends a Renew option after T1. It includes the " section="7.7" sectionFormat="of"/>). The client sends a Renew option after T1.
preferred SLAP quadrant(s) in the new QUAD IA_LL-option, so in case the server 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 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. quadrants are known for the allocation of any "new" (i.e., different) addresses.
</t> </li>
<li>
<t> The server responds with a Reply message with an IA_LL option that includes an
The server responds with a Reply message, with an IA_LL option that includes an
LLADDR option with extended lifetime. LLADDR option with extended lifetime.
</t> </li>
</ol>
</list>
</t>
<t> <t>
The client SHOULD check if the received MAC address comes from one of the The client <bcp14>SHOULD</bcp14> check if the received MAC address comes from on
requested quadrants. It MAY repeat the process selecting a different DHCP server e of the
. requested quadrants. It <bcp14>MAY</bcp14> repeat the process selecting a differ
ent DHCP server.
</t> </t>
</section> </section>
<section anchor="sec_dhcpv6_ext_relay" numbered="true"
toc="default">
<section anchor="sec:dhcpv6_ext_relay" title="Address Assignment from the <name>Address Assignment from the Preferred SLAP Quadrant Indicated by t
SLAP Quadrant Indicated by the Relay"> he Relay</name>
<t> <t>
Next, we describe the protocol operations for a relay to select a preferred Next, we describe the protocol operations for a relay to select a preferred
SLAP quadrant using the DHCPv6 signaling procedures described in <xref SLAP quadrant using the DHCPv6 signaling procedures described in <xref target="R
target="I-D.ietf-dhc-mac-assign" />. This is useful when a DHCPv6 server is FC8947" format="default"/>. This is useful when a DHCPv6 server is
operating over a large infrastructure split in different network regions, where operating over a large infrastructure split in different network regions, where
each region might have different requirements. The signaling flow is shown in each region might have different requirements. The signaling flow is shown in
<xref target="fig:dhcpv6_flow_relay" />. <xref target="fig_dhcpv6_flow_relay" format="default"/>.
</t> </t>
<figure anchor="fig:dhcpv6_flow_relay" title="DHCPv6 signaling flow (client-rela <figure anchor="fig_dhcpv6_flow_relay">
y-server)" > <name>DHCPv6 Signaling Flow (Client-Relay-Server)</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| DHCPv6 | | DHCPv6 | | DHCPv6 | | DHCPv6 | | DHCPv6 | | DHCPv6 |
| client | | relay | | server | | client | | relay | | server |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | |
+-----1. Solicit(IA_LL)----->| | +-----1. Solicit(IA_LL)----->| |
| +----2. Relay-forward | | +----2. Relay-forward |
| | (Solicit(IA_LL),QUAD)------>| | | (Solicit(IA_LL),QUAD)------>|
| | | | | |
| |<---3. Relay-reply | | |<---3. Relay-reply |
| | (Advertise(IA_LL(LLADDR)))--+ | | (Advertise(IA_LL(LLADDR)))--+
|<4. Advertise(IA_LL(LLADDR))+ | |<4. Advertise(IA_LL(LLADDR))+ |
|-5. Request(IA_LL(LLADDR))->| | |-5. Request(IA_LL(LLADDR))->| |
| +-6. Relay-forward | | +-6. Relay-forward |
| | (Request(IA_LL(LLADDR)),QUAD)->| | | (Request(IA_LL(LLADDR)),QUAD)->|
| | | | | |
| |<--7. Relay-reply | | |<--7. Relay-reply |
| | (Reply(IA_LL(LLADDR)))-------+ | | (Reply(IA_LL(LLADDR)))-------+
|<--8. Reply(IA_LL(LLADDR))--+ | |<--8. Reply(IA_LL(LLADDR))--+ |
| | | | | |
· · · . . .
· (timer expiring) · . (timer expiring) .
· · · . . .
| | | | | |
+--9. Renew(IA_LL(LLADDR))-->| | +--9. Renew(IA_LL(LLADDR))-->| |
| |--10. Relay-forward | | |--10. Relay-forward |
| | (Renew(IA_LL(LLADDR)),QUAD)-->| | | (Renew(IA_LL(LLADDR)),QUAD)-->|
| | | | | |
| |<---11. Relay-reply | | |<---11. Relay-reply |
| | (Reply(IA_LL(LLADDR)))-----+ | | (Reply(IA_LL(LLADDR)))-----+
|<--12. Reply(IA_LL(LLADDR)--+ | |<--12. Reply(IA_LL(LLADDR))-+ |
| | | | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<ol spacing="normal" type="1"><li>
<t>
<list style="numbers">
<t>
Link-layer addresses (i.e., MAC addresses) are assigned in blocks. The smallest 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 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 message with an IA_LL option in the message. The IA_LL option <bcp14>MUST</bcp14 > contain an
LLADDR option. LLADDR option.
</t> </li>
<li>
<t>
The DHCP relay receives the Solicit message and encapsulates it in a The DHCP relay receives the Solicit message and encapsulates it in a
Relay-forward message. The relay, based on local knowledge and policies, Relay-forward message. The relay, based on local knowledge and policies,
includes in the Relay-forward message the QUAD option with the preferred includes in the Relay-forward message the QUAD option with the preferred
quadrant. The relay might know which quadrant to request based on local quadrant. The relay might know which quadrant to request based on local
configuration (e.g., the served network contains IoT devices only, thus configuration (e.g., the served network contains IoT devices only, thus
requiring ELI/SAI) or other means. Note that if a client sends multiple 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 instances of the IA_LL option in the same message, the DHCP relay <bcp14>MAY</bc p14> only
add a single instance of the QUAD option. add a single instance of the QUAD option.
</t> </li>
<li>
<t>
Upon receiving a relayed message containing an IA_LL option, the server inspects 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 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 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 instance of the option to process is selected (see the end of this
section). For each of the entries in OPTION_SLAP_QUAD, in order of the 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 preference field (highest to lowest), the server checks if it has a configured
MAC address pool matching the requested quadrant identifier, and an available MAC address pool matching the requested quadrant identifier and an available
range of addresses of the requested size. If suitable addresses are found, the 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 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 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 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 preferred quadrant included in the QUAD option and manages a block of addresses
belonging to a requested quadrant, then the addresses being offered MUST belonging to a requested quadrant, then the addresses being offered <bcp14>MUST<
belong to a requested quadrant. The server SHOULD apply the contents of the /bcp14>
belong to a requested quadrant. The server <bcp14>SHOULD</bcp14> apply the conte
nts of the
relay's supplied QUAD option for all of the client's IA_LLs, unless configured relay's supplied QUAD option for all of the client's IA_LLs, unless configured
to do otherwise. to do otherwise.
</t> </li>
<li>
<t>
The relay sends the received Advertise message to the client. The relay sends the received Advertise message to the client.
</t> </li>
<li>
<t>
The client waits for available servers to send Advertise responses and picks one The client waits for available servers to send Advertise responses and picks one
server as defined in Section 18.2.9 of <xref target="RFC8415" server, as defined in <xref target="RFC8415" section="18.2.9" sectionFormat="of"
/>. The client then sends a Request message that includes the IA_LL container />. 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 option with the LLADDR option copied from the Advertise message sent by the
chosen server. chosen server.
</t> </li>
<li>
<t> The relay forwards the received Request in a Relay-forward message. It adds, in
The relay forwards the received Request in a Relay-forward message. It adds in t the
he Relay-forward, a QUAD IA_LL option with the preferred quadrant.
Relay-forward a QUAD IA_LL-option with the preferred quadrant. </li>
</t> <li>
<t>
Upon reception of the forwarded Request message with IA_LL container option, the 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 server assigns requested addresses. The server <bcp14>MAY</bcp14> alter the allo
time. It then generates and sends a Reply message, in a Relay-reply back to the cation at this
time. It then generates and sends a Reply message in a Relay-reply
message back to the
relay. relay.
</t> </li>
<li>
<t>
Upon receiving a Reply message, the client parses the IA_LL container option and Upon receiving a Reply message, the client parses the IA_LL container option and
may start using all provided addresses. may start using all provided addresses.
</t> </li>
<li>
<t> The client is expected to periodically renew the link-layer addresses, as
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 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 <xref the server sending "infinity" as the T1 and T2 values (see <xref target="RFC8415
target="RFC8415" />). The client sends a Renew option after T1. " section="7.7" sectionFormat="of"/>). The client sends a Renew option after T1.
</t> </li>
<li>
<t>
This message is forwarded by the relay in a Relay-forward message, including a Q UAD This message is forwarded by the relay in a Relay-forward message, including a Q UAD
IA_LL-option with the preferred quadrant. IA_LL option with the preferred quadrant.
</t> </li>
<li>
<t>
The server responds with a Reply message, including an LLADDR option with The server responds with a Reply message, including an LLADDR option with
extended lifetime. This message is sent in a Relay-reply message. extended lifetime. This message is sent in a Relay-reply message.
</t> </li>
<li>
<t>
The relay sends the Reply message back to the client. The relay sends the Reply message back to the client.
</t> </li>
</ol>
</list>
</t>
<t> <t>
The server SHOULD implement a configuration parameter to deal with the case The server <bcp14>SHOULD</bcp14> implement a configuration parameter to deal wit
where the client's DHCP message contains an instance of OPTION_SLAP_QUAD, and h&nbsp;the case
the relay adds a second instance in its relay-forward message. This parameter where the client's DHCP message contains an instance of OPTION_SLAP_QUAD and
configures the server to process either the client's, or the relay's instance of the relay adds a second instance in its Relay-forward message. This parameter
option QUAD. It is RECOMMENDED that the default for such a parameter is to configures the server to process either the client's or the relay's instance of
option QUAD. It is <bcp14>RECOMMENDED</bcp14> that the default for such a parame
ter is to
process the client's instance of the option. process the client's instance of the option.
</t> </t>
<t> <t>
The client MAY check if the received MAC address belongs to a quadrant it is The client <bcp14>MAY</bcp14> check if the received MAC address belongs to a qua
willing to use/configure, and MAY decide based on that whether to use configure drant it is
willing to use/configure and <bcp14>MAY</bcp14> decide based on that whether to
use/configure
the received address. the received address.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec_dhcpv6_options" numbered="true" toc="default">
<section anchor="sec:dhcpv6_options" title="DHCPv6 Option Definition"> <name>DHCPv6 Option Definition</name>
<section anchor="sec_quad_IA_LL" numbered="true" toc="default">
<section anchor="sec:quad_IA_LL" <name>QUAD Option</name>
title="Quad option">
<t> <t>
The QUAD option is used to specify the preferences for the selected quadrants 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 within an IA_LL. The option <bcp14>MUST</bcp14> be encapsulated either in the IA _LL-options
field of an IA_LL option or in a Relay-forward message. field of an IA_LL option or in a Relay-forward message.
</t> </t>
<t> <t>
The format of the QUAD option is: The format of the QUAD option is:
</t> </t>
<figure anchor="quad-option">
<figure align="center" anchor="quad-option" <name>QUAD Option Format</name>
title="Quad Option Format"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
0 1 2 3 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 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 | | OPTION_SLAP_QUAD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| quadrant-1 | pref-1 | quadrant-2 | pref-2 | | quadrant-1 | pref-1 | quadrant-2 | pref-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| quadrant-n-1 | pref-n-1 | quadrant-n | pref-n | | quadrant-n-1 | pref-n-1 | quadrant-n | pref-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="16">
<t> <dt>option-code</dt>
<list hangIndent="16" style="hanging"> <dd>
<t hangText="option-code"> OPTION_SLAP_QUAD (140).
OPTION_SLAP_QUAD (IANA-1). </dd>
</t> <dt>option-len</dt>
<dd>
<t hangText="option-len"> 2 * number of included (quadrant, preference). This is a 2-byte field containing
2 * number of included (quadrant, preference). A 2-byte field containing the the
total length of all (quadrant, preference) pairs included in the option. total length of all (quadrant, preference) pairs included in the option.
</t> </dd>
<dt>quadrant-n</dt>
<t hangText="quadrant-n"> <dd>
Identifier of the quadrant (0: AAI, 1: ELI, 2: Reserved by IEEE Identifier of the quadrant (0: AAI, 1: ELI, 2: Reserved by IEEE
<xref target="IEEEStd802c" />, 3: SAI). Each quadrant <xref target="IEEEStd802c" format="default"/>, and 3: SAI). Each quadrant
MUST only appear once at most in the option. A 1-byte field. <bcp14>MUST</bcp14> only appear once at most in the option. This is a 1-byte fie
</t> ld.
</dd>
<t hangText="pref-n"> <dt>pref-n</dt>
<dd>
Preference associated to quadrant-n. A higher value means a more preferred Preference associated to quadrant-n. A higher value means a more preferred
quadrant. A 1-byte field. quadrant. This is a 1-byte field.
</t> </dd>
</dl>
</list>
</t>
<t> <t>
A quadrant identifier value MUST only appear at most once in the option. If A quadrant identifier value <bcp14>MUST</bcp14> only appear, at most, once in th
an option includes more than one occurrence of the same quadrant identifier, e option.&nbsp;If
only the first occurence is processed and the rest MUST be ignored by the an&nbsp;option includes more than one occurrence of the same quadrant identifier
,
only the first occurrence is processed, and the rest <bcp14>MUST</bcp14> be igno
red by the
server. server.
</t> </t>
<t> <t>
If the same preference value is used for more than one quadrant, 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 <bcp14>MAY</bcp14> select which quadrant should be preferred (if the server can assign
addresses from all or some of the quadrants with the same assigned 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). Note that this is not a simple list of quadrants ordered by
preference without no preference value but a list of quadrants with explicit preference with no preference value, but a list of quadrants with explicit
preference values. This way it can support the case whereby a client really 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 has no preference between two or three quadrants, leaving the decision to the
server. server.
</t> </t>
<t> <t>
If the client or relay agent provide the OPTION_SLAP_QUAD, the server MUST use If the client or relay agent provides the OPTION_SLAP_QUAD, the server <bcp14>MU ST</bcp14> use
the quadrant-n/pref-n values to order the selection of the quadrants. If the 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 server can provide an assignment from one of the specified quadrants, it <bcp14> SHOULD</bcp14>
proceed with the assignment. If the server does not have a configured address proceed with the assignment. If the server does not have a configured address
pool matching any of the specified quadrant-n fields, or if the server has a pool matching any of the specified quadrant-n fields or if the server has a
configured address pool of the correct quadrant, but no available addresses, configured address pool of the correct quadrant but no available addresses,
it MUST return the IA_LL option containing a status of NoAddrsAvail. it <bcp14>MUST</bcp14> return the IA_LL option containing a status of NoAddrsAva
il.
</t> </t>
<t> <t>
There is no requirement that the client or relay agent order the quadrant/pref 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 values in any specific order; hence, servers <bcp14>MUST NOT</bcp14> assume that
quadrant-1/pref-1 have the highest preference (except if there is only 1 set of quadrant-1/pref-1 have the highest preference (except if there is only one set o
f
values). values).
</t> </t>
<t> <t>
For cases where a server may not be configured to have pools for the client or 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 relay quadrant preferences, clients and relays <bcp14>SHOULD</bcp14> specify all quadrants in
the QUAD option to assure the client gets an address (or addresses) -- if any 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 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 server responding like a non-QUAD option supporting server, i.e., an address (or
addresses) from any available quadrants can be returned. addresses) from any available quadrants can be returned.
</t> </t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <t>IANA has assigned the QUAD (140)
option code from the "Option Codes" subregistry of the
<t> "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained a
IANA is requested to assign the QUAD (IANA-1) option code from the DHCPv6 t
"Option Codes" registry maintained at <eref target="http://www.iana.org/assignments/dhcpv6-parameters" brackets="an
http://www.iana.org/assignments/dhcpv6-parameters and use the following data gle"/>:</t>
when adding the option to the registry:
</t>
<figure>
<artwork align="left">
<![CDATA[
Value: IANA-1
Description: OPTION_SLAP_QUAD
Client ORO: No
Singleton Option: No
Reference: this document
]]>
</artwork>
</figure>
<dl spacing="compact">
<dt>Value:</dt><dd>140</dd>
<dt>Description:</dt><dd>OPTION_SLAP_QUAD</dd>
<dt>Client ORO:</dt><dd>No</dd>
<dt>Singleton Option:</dt><dd>Yes</dd>
<dt> Reference:</dt><dd>RFC 8948</dd>
</dl>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
See <xref target="RFC8415" /> and <xref target="RFC7227" /> for the DHCPv6 See <xref target="RFC8415" format="default"/> and <xref target="RFC7227" format=
security and privacy considerations. See <xref target="RFC8200" /> for the IPv6 "default"/> for the DHCPv6
security and privacy considerations. See <xref target="RFC8200" format="default"
/> for the IPv6
security considerations. security considerations.
</t> </t>
<t> <t>
See also <xref target="I-D.ietf-dhc-mac-assign" /> for security considerations Also, see <xref target="RFC8947" format="default"/> for security consider ations
regarding link-layer address assignments using DHCP. regarding link-layer address assignments using DHCP.
</t> </t>
</section> </section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
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, &Eacute;ric
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 and references.
</t>
<t>
The work in document draft has been supported by the H2020 5Growth (Grant
856709) and 5G-DIVE projects (Grant 859881).
</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8415.xml"/>
<reference anchor='RFC8947' target="https://www.rfc-editor.org/info/rfc8947">
<front>
<title>Link-Layer Addresses Assignment Mechanism for DHCPv6</title>
<author initials='B' surname='Volz' fullname='Bernie Volz'>
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials='T' surname='Mrugalski' fullname='Tomek Mrugalski'>
<organization>Internet Systems Consortium, Inc.</organization>
</author>
<author initials='CJ' surname='Bernardos' fullname='Carlos J. Bernardos'>
<organization>Universidad Carlos III de Madrid</organization>
</author>
<date month='November' year='2020'/>
</front>
<seriesInfo name="RFC" value="8947"/>
<seriesInfo name="DOI" value="10.17487/RFC8947"/>
</reference>
<references title="Normative References"> </references>
&rfc2119; <references>
&rfc8174; <name>Informative References</name>
&rfc8415; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&I-D.ietf-dhc-mac-assign; FC.8200.xml"/>
</references>
<references title="Informative References">
&rfc8200;
<reference anchor="IEEEStd802c">
<front>
<title>
IEEE Standard for Local and Metropolitan Area Networks: Overview a
nd Architecture,
Amendment 2: Local Medium Access Control (MAC) Address Usage, IEEE
Std 802c-2017
</title>
<author>
<organization>IEEE</organization>
</author>
<date month="June" year="2017" />
</front> <reference anchor="IEEEStd802c">
</reference> <front>
<title>
IEEE Standard for Local and Metropolitan Area Networks: Overview
and Architecture -- Amendment 2: Local Medium Access Control (MAC)
Address Usage
</title>
<author>
<organization>IEEE</organization>
</author>
<date month="August" year="2017"/>
</front>
<seriesInfo name="IEEE Std" value="802c-2017"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8016709"/>
</reference>
<reference anchor="IEEEStd802"> <reference anchor="IEEEStd802">
<front> <front>
<title> <title>
IEEE Standard for Local and IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture, IEEE Std 80 Metropolitan Area Networks: Overview and Architecture
2-2014 </title>
</title> <author>
<organization>IEEE</organization>
<author> </author>
<organization>IEEE</organization> <date month="June" year="2014"/>
</author> </front>
<seriesInfo name="IEEE Std" value="802-2014"/>
<date month="June" year="2014" /> <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
</reference>
</front>
</reference>
<reference anchor="IEEE-P802.1CQ-Project">
<front>
<title>
IEEE P802.1CQ: Multicast and Local Address Assignment
</title>
<author>
<organization>IEEE</organization>
</author>
<date />
</front>
</reference>
&rfc7228;
&rfc7548;
&rfc7227;
<reference anchor="IEEE-P802.1CQ-Project" target="https://standards.ieee
.org/project/802_1CQ.html">
<front>
<title>
P802.1CQ - Standard for Local and Metropolitan Area Networks:
Multicast and Local Address Assignment
</title>
<author>
<organization>IEEE</organization>
</author>
</front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7228.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7548.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7227.xml"/>
</references>
</references> </references>
<section anchor="sec_quadrant_selection" numbered="true" toc="default">
<section anchor="sec:quadrant_selection" title="Quadrant Selection Mechanism <name>Example Uses of Quadrant Selection Mechanisms</name>
s examples"> <t>
<t>
This appendix describes some examples of how the quadrant preference mechanisms This appendix describes some examples of how the quadrant preference mechanisms
could be used. could be used.
</t> </t>
<t>
<t> First, let's take an IoT scenario as an example. An IoT device might decide on
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 its own the SLAP quadrant it wants to use to obtain a local MAC address, using
the following information to take the decision: the following information to make the decision:
<list style="symbols"> </t>
<t> <ul spacing="normal">
Type of IoT deployment: e.g., industrial, domestic, rural, etc. For small <li>Type of IoT deployment: For example, industrial, domestic, rural, etc
. For small
deployments, such as domestic ones, the IoT device itself can decide to use the AAI 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 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 configuring a random address computed by the device itself). For large
deployments, such as industrial or rural ones, where thousands of devices 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. might coexist, the IoT can decide to use the ELI or SAI quadrants.</li>
</t>
<t> <li>Mobility: If the IoT device can move, then it might prefer to select the SAI
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. 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 If the device is known to remain fixed, then the ELI is probably the most
suitable one to use. suitable one to use.</li>
</t>
<t> <li>Managed/Unmanaged: Depending on whether the IoT device is managed during its
Managed/unmanaged: depending on whether the IoT device is managed during its lifetime or cannot be reconfigured <xref target="RFC7548" format="default"/>, th
lifetime or cannot be re-configured <xref target="RFC7548" />, the decision of e decision of
what quadrant is more appropriate might be different. For example, if the IoT what quadrant is more appropriate might be different. For example, if the IoT
device can be managed (e.g., configured), and network topology changes might device can be managed (e.g., configured) and network topology changes might
occur during its lifetime (e.g., due to changes on the deployment, such as 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 extensions involving additional devices), this has an impact on the preferred
quadrant (e.g., to avoid potential collisions in the future). quadrant (e.g., to avoid potential collisions in the future).</li>
</t>
<t> <li>Operation / Battery Lifetime: Depending on the expected lifetime of the devi
Operation/battery lifetime: depending on the expected lifetime of the device a ce, a
different quadrant might be preferred (as before, to minimize potential address different quadrant might be preferred (as before, to minimize potential address
collisions in the future). collisions in the future).</li>
</t> </ul>
</list>
<t>
The previous parameters are considerations that the device vendor/administrator 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., may wish to use when defining the IoT device's MAC&nbsp;address request policy ( i.e.,
how to select a given SLAP quadrant). IoT devices are typically very resource 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 constrained, so there may only be a simple decision-making process based on
pre-configured preferences. preconfigured preferences.
</t> </t>
<t>
<t> We now take the Wi-Fi device scenario, considering, for example, that a laptop
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
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 privacy/security concerns, the device might want to configure a local MAC
address. The device might use different parameters and context information to address. The device might use different parameters and context information to
decide, not only which SLAP quadrant to use for the local MAC address 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 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 needed to change address several times). This information includes, but it is
not limited to: not limited to:
<list style="symbols"> </t>
<ul spacing="normal">
<t> <li>
Type of network the device is connected: public, work, home. Type of network the device is connected: public, work, home.
</t> </li>
<li>
<t>
Trusted network: Yes/No. Trusted network: Yes/No.
</t> </li>
<li>
<t>
First time visited network: Yes/No. First time visited network: Yes/No.
</t> </li>
<li>
<t>
Network geographical location. Network geographical location.
</t> </li>
<li>
<t> Mobility: Yes (the device might change its network attachment point) / No (the
Mobility: Yes (the device might change its network attachment point)/No (the
device is not going to change its network attachment point). device is not going to change its network attachment point).
</t> </li>
<li>
<t> Operating System (OS) network profile, including security/trust-related
Operating System (OS) network profile, including security/trust related parameters: Most modern OSs keep metadata associated with the networks they can
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
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 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 terms of advertising itself on the network, firewall settings, etc.
information can also be used to decide whether to configure a local MAC address
or not, from which SLAP quadrant and how often.
</t>
<t>
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.
</t>
</list>
</t>
<t> But this information can also be used to decide whether or not to configure a
local MAC address, from which SLAP quadrant it should be assigned, and how
often it may be assigned.
</li>
<li>
Triggers coming from applications regarding location privacy: An app might
request that the OS maximize location privacy (due to the nature of the
application), and this might require the OS to force the use of a local MAC
address or the local MAC address to be changed.
</li>
</ul>
<t>
This information can be used by the device to select the SLAP quadrant. For 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 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 network in an airport), it is likely that it might change access points several
times, and therefore it is best to minimize the chances of address collision, 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 attach using the SAI or AAI quadrants. If the device is not expected to move
ed to a and is attached to a
trusted network (e.g. in some scenarios at work), then it is probably best to se trusted network (e.g., in some scenarios at work), then it is probably best to s
lect the ELI elect the ELI
quadrant. These are just some examples of how to use this information to select quadrant. These are just some examples of how to use this information to select
the quadrant. the quadrant.
</t> </t>
<t>
<t>
Additionally, the information can also be used to trigger subsequent changes of Additionally, the information can also be used to trigger subsequent changes of
MAC address, to enhance location privacy. Besides, changing the SLAP MAC address to enhance location privacy. Besides, changing the SLAP
quadrant might also be used as an additional enhancement to make it harder to tr ack quadrant might also be used as an additional enhancement to make it harder to tr ack
the user location. the user location.
</t> </t>
<t>
<t> Last, if we consider the data-center scenario, a hypervisor might request local
Last, if we consider the data center scenario, a hypervisor might request local MAC addresses be assigned to virtual machines. As in the previous scenarios,
MAC addresses to be assigned to virtual machines. As in the previous scenarios,
the hypervisor might select the preferred SLAP quadrant using information the hypervisor might select the preferred SLAP quadrant using information
provided by the cloud management system or virtualization infrastructure provided by the cloud management system or virtualization infrastructure
manager running on top of the hypervisor. This information might include, manager running on top of the hypervisor. This information might include,
but is not limited to: but is not limited to:
<list style="symbols"> </t>
<ul spacing="normal">
<t> <li>
Migratable VM. If the function implemented by the VM is subject to be moved to 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 another physical server or not, this has an impact on the preference for the
SLAP quadrant, as the ELI and SAI quadrants are better suited for supporting SLAP quadrant, as the ELI and SAI quadrants are better suited for supporting
migration in a large data center. migration in a large data center.
</t> </li>
<li>
<t> VM connectivity characteristics: For example, standalone, part of a pool, and pa
VM connectivity characteristics , e.g., standalone, part of a pool, part of a rt of a
service graph/chain. If the connectivity characteristics of the VM are known, 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. this can be used by the hypervisor to select the best SLAP quadrant.
</t> </li>
</ul>
</list> </section>
<section anchor="Acknowledgments" numbered="false" toc="default">
</t> <name>Acknowledgments</name>
<t>
The authors would like to thank <contact fullname="Bernie Volz"/> for
his very valuable comments on this document. We also want to thank
<contact fullname="Ian Farrer"/>, <contact fullname="Tomek
Mrugalski"/>, <contact fullname="Éric Vyncke"/>, <contact
fullname="Tatuya Jinmei"/>, <contact fullname="Carl Wallace"/>,
<contact fullname="Ines Robles"/>, <contact fullname="Ted Lemon"/>,
<contact fullname="Jaime Jimenez"/>, <contact fullname="Robert Wilton"/>,
<contact fullname="Benjamin Kaduk"/>,
<contact fullname="Barry Leiba"/>, <contact fullname="Alvaro
Retana"/>, and
<contact fullname="Murray Kucherawy"/>
for their very detailed and helpful reviews. And thanks to <contact fullname="Ro
ger
Marks"/> and <contact fullname="Antonio de la Oliva"/> for comments related to
IEEE work and references.
</t>
<t>
The work in this document has been supported by the H2020 5GROWTH (Grant
856709) and 5G-DIVE projects (Grant 859881).
</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 185 change blocks. 
664 lines changed or deleted 612 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/