draft-ietf-dhc-slap-quadrant-01.txt   draft-ietf-dhc-slap-quadrant-02.txt 
DHC WG CJ. Bernardos DHC WG CJ. Bernardos
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Standards Track A. Mourad Intended status: Standards Track A. Mourad
Expires: January 9, 2020 InterDigital Expires: July 16, 2020 InterDigital
July 8, 2019 January 13, 2020
SLAP quadrant selection options for DHCPv6 SLAP quadrant selection options for DHCPv6
draft-ietf-dhc-slap-quadrant-01 draft-ietf-dhc-slap-quadrant-02
Abstract Abstract
The IEEE originally structured the 48-bit MAC address space in such a 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 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 has been working on a new specification (IEEE 802c) which defines a
new "optional Structured Local Address Plan" (SLAP) that specifies new "optional Structured Local Address Plan" (SLAP) that specifies
different assignment approaches in four specified regions of the different assignment approaches in four specified regions of the
local MAC address space. local MAC address space.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020. This Internet-Draft will expire on July 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4
1.1.1. WiFi devices . . . . . . . . . . . . . . . . . . . . 4 1.1.1. WiFi devices . . . . . . . . . . . . . . . . . . . . 4
1.1.2. Hypervisor: migratable vs non-migratable functions . 5 1.1.2. Hypervisor: migratable vs non-migratable functions . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Quadrant selection mechanisms . . . . . . . . . . . . . . . . 6 3. Quadrant Selection Mechanisms . . . . . . . . . . . . . . . . 6
4. DHCPv6 extensions . . . . . . . . . . . . . . . . . . . . . . 8 4. DHCPv6 extensions . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Address assignment from the preferred SLAP quadrant 4.1. Address Assignment from the Preferred SLAP Quadrant
indicated by the client . . . . . . . . . . . . . . . . . 9 Indicated by the Client . . . . . . . . . . . . . . . . . 9
4.2. Address assignment from the SLAP quadrant indicated by 4.2. Address Assignment from the SLAP Quadrant Indicated by
the relay . . . . . . . . . . . . . . . . . . . . . . . . 10 the Relay . . . . . . . . . . . . . . . . . . . . . . . . 10
5. DHCPv6 options definitions . . . . . . . . . . . . . . . . . 13 5. DHCPv6 Options Definitions . . . . . . . . . . . . . . . . . 13
5.1. Quad (IA-LL) option . . . . . . . . . . . . . . . . . . . 13 5.1. Quad (IA-LL) option . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The IEEE originally structured the 48-bit MAC address space in such a 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 U/L bit is way that half of it was reserved for local use (where the U/L bit is
set to 1). Recently, the IEEE has been working on a new set to 1). Recently, the IEEE has been working on a new
specification (IEEE 802c [IEEEStd802c-2017]) which defines a new specification (IEEE 802c [IEEEStd802c-2017]) which defines a new
"optional Structured Local Address Plan" (SLAP) that specifies "optional Structured Local Address Plan" (SLAP) that specifies
different assignment approaches in four specified regions of the different assignment approaches in four specified regions of the
local MAC address space. These four regions, called SLAP quadrants, local MAC address space. These four regions, called SLAP quadrants,
skipping to change at page 4, line 43 skipping to change at page 4, line 43
sometimes short lived and disposable devices. Examples of this sometimes short lived and disposable devices. Examples of this
include: sensors and actuators for health or home automation include: sensors and actuators for health or home automation
applications. In this scenario, it is common that upon a first applications. In this scenario, it is common that upon a first
boot, the device uses a temporary MAC address, to send initial boot, the device uses a temporary MAC address, to send initial
DHCP packets to available DHCP servers. IoT devices typically DHCP packets to available DHCP servers. IoT devices typically
request a single MAC address for each available network interface. request a single MAC address for each available network interface.
Once the server assigns a MAC address, the device abandons its Once the server assigns a MAC address, the device abandons its
temporary MAC address. This type of device is typically not temporary MAC address. This type of device is typically not
moving. In general, any type of SLAP quadrant would be good for moving. In general, any type of SLAP quadrant would be good for
assigning addresses from, but ELI/SAI quadrants might be more assigning addresses from, but ELI/SAI quadrants might be more
suitable in some scenarios, such as if it is needed that the suitable in some scenarios, such as if the addresses need to
addresses belong to the CID assigned to the IoT communication belong to the CID assigned to the IoT communication device vendor.
device vendor.
o Privacy: Today, MAC addresses allow the exposure of users' o Privacy: Today, MAC addresses allow the exposure of users'
locations making it relatively easy to track users' movement. One locations making it relatively easy to track users' movement. One
of the mechanisms considered to mitigate this problem is the use of the mechanisms considered to mitigate this problem is the use
of local random MAC addresses, changing them every time the user of local random MAC addresses, changing them every time the user
connects to a different network. In this scenario, devices are connects to a different network. In this scenario, devices are
typically mobile. Here, AAI is probably the best SLAP quadrant to typically mobile. Here, AAI is probably the best SLAP quadrant to
assign addresses from, as it is the best fit for randomization of assign addresses from, as it is the best fit for randomization of
addresses, and it is not required for the addresses to survive addresses, and it is not required for the addresses to survive
when changing networks. when changing networks.
skipping to change at page 5, line 25 skipping to change at page 5, line 24
acts as a DHCP client and requests available DHCP servers to assign acts as a DHCP client and requests available DHCP servers to assign
one or more MAC addresses (an address block). The hypervisor does one or more MAC addresses (an address block). The hypervisor does
not use those addresses for itself, but rather uses them to create not use those addresses for itself, but rather uses them to create
new VMs with appropriate MAC addresses. If we assume very large data new VMs with appropriate MAC addresses. If we assume very large data
center environments, such as the ones that are typically used center environments, such as the ones that are typically used
nowadays, it is expected that the data center is divided in different nowadays, it is expected that the data center is divided in different
network regions, each one managing its own local address space. In network regions, each one managing its own local address space. In
this scenario, there are two possible situations that need to be this scenario, there are two possible situations that need to be
tackled: tackled:
o Migratable functions. If a VM (providing a given function) might o Migratable functions. If a VM (providing a given function) needs
need to be potentially migrated to another region of the data to be migrated to another region of the data center (e.g., for
center (due to maintenance, resilience, end-user mobility, etc.) maintenance, resilience, end-user mobility, etc.), the VM's
it is needed that this VM can keep its networking context in the networking context needs to migrate with the VM. This includes
new region, and this includes keeping its MAC addresses. the VM's MAC address(es). Therefore, for this case, it is better
Therefore, for this case, it is better to allocate addresses from to allocate addresses from the ELI/SAI SLAP quadrant, which can be
the ELI/SAI SLAP quadrant, which can be centrally allocated by the centrally allocated by the DHCP server.
DHCP server.
o Non-migratable functions. If a VM will not be migrated to another o Non-migratable functions. If a VM will not be migrated to
region of the data center, there are no requirements associated to another region of the data center, there are no requirements
its MAC address, and then it is more efficient to allocate it from associated with its MAC address. In this case, it is more
the AAI SLAP quadrant, which does not need to be same for all the efficient to allocate it from the AAI SLAP quadrant, that does not
data centers (i.e., each region can manage its own, without need to be unique across multiple data centers (i.e., each region
checking for duplicates globally). can manage its own MAC address assignment, without checking for
duplicates globally).
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The DHCPv6 terminology relevant to this specification from the DHCPv6 Where relevant, the DHCPv6 terminology from the DHCPv6 Protocol
Protocol [RFC8415] applies here. [RFC8415] also applies here. Additionally, the following definitions
are updated for this document.
client A device that is interested in obtaining link-layer client A device that is interested in obtaining link-layer
addresses. It implements the basic DHCPv6 mechanisms addresses. It implements the basic DHCPv6 mechanisms
needed by a DHCPv6 client as described in [RFC8415] and needed by a DHCPv6 client as described in [RFC8415] and
supports the new options (IA_LL and LLADDR) specified supports the new options (IA_LL and LLADDR) specified
in [I-D.ietf-dhc-mac-assign]. The client may or may in [I-D.ietf-dhc-mac-assign]. The client may or may
not support address assignment and prefix delegation as not support address assignment and prefix delegation as
specified in [RFC8415]. specified in [RFC8415].
server Software that manages link-layer address allocation and server Software that manages link-layer address allocation and
is able to respond to client queries. It implements is able to respond to client queries. It implements
basic DHCPv6 server functionality as described in basic DHCPv6 server functionality as described in
[RFC8415] and supports the new options (IA_LL and [RFC8415] and supports the new options (IA_LL and
LLADDR) specified in [I-D.ietf-dhc-mac-assign]. The LLADDR) specified in [I-D.ietf-dhc-mac-assign]. The
server may or may not support address assignment and server may or may not support address assignment and
prefix delegation as specified in [RFC8415]. 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 in [RFC8415] and supports
the new options (IA_LL and LLADDR) specified in
[I-D.ietf-dhc-mac-assign].
address Unless specified otherwise, an address means a link- address Unless specified otherwise, an address means a link-
layer (or MAC) address, as defined in IEEE802. The layer (or MAC) address, as defined in IEEE802. The
address is typically 6 bytes long, but some network address is typically 6 bytes long, but some network
architectures may use different lengths. architectures may use different lengths.
address block A number of consecutive link-layer addresses. An address block A number of consecutive link-layer addresses. An
address block is expressed as a first address plus a address block is expressed as a first address plus a
number that designates the number of additional (extra) number that designates the number of additional (extra)
addresses. A single address can be represented by the addresses. A single address can be represented by the
address itself and zero extra addresses. address itself and zero extra addresses.
3. Quadrant selection mechanisms 3. Quadrant Selection Mechanisms
We next describe some exemplary ways to perform SLAP quadrant The following section describes some examples of how the quadrant
selection. These are provided just as informational text to preference mechanisms could be used.
exemplify how the quadrant preference mechanisms could be used.
Let's take first an IoT scenario as an example. An IoT device might 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 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: MAC address, using the following information to take the decision:
o Type of IoT deployment: e.g., industrial, domestic, rural, etc. o Type of IoT deployment: e.g., industrial, domestic, rural, etc.
For small deployments, such as domestic ones, the IoT itself can For small deployments, such as domestic ones, the IoT itself can
decide to use the AAI quadrant (this might not even involve the decide to use the AAI quadrant (this might not even involve the
use of DHCP, by the device just configuring a random address use of DHCP, by the device just configuring a random address
computed by the device itself). For large deployments, such as computed by the device itself). For large deployments, such as
skipping to change at page 7, line 20 skipping to change at page 7, line 27
means that network topology changes might occur during its means that network topology changes might occur during its
lifetime (e.g., due to changes on the deployment, such as lifetime (e.g., due to changes on the deployment, such as
extensions involving additional devices), and this might have an extensions involving additional devices), and this might have an
impact on the preferred quadrant (e.g., to avoid potential impact on the preferred quadrant (e.g., to avoid potential
collisions in the future). collisions in the future).
o Operation/battery lifetime: depending on the expected lifetime of o Operation/battery lifetime: depending on the expected lifetime of
the device a different quadrant might be preferred (as before, to the device a different quadrant might be preferred (as before, to
minimize potential address collisions in the future). minimize potential address collisions in the future).
The previous are examples of parameters that an IoT device might use The previous are considerations that the device vendor/administrator
to select a given SLAP quadrant. IoT devices are typically very may wish to use when defining the IoT device's MAC address request
resource constrained, so it might be as well that simple decisions policy (i.e., how to select a given SLAP quadrant). IoT devices are
are just taken, for example based on pre-configured preferences. 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 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 a laptop or smartphone connects to a network using its built in MAC
address. Due to privacy/security concerns, the device might want to address. Due to privacy/security concerns, the device might want to
configure a local MAC address. The device might use different configure a local MAC address. The device might use different
parameters and context information to decide, not only which SLAP parameters and context information to decide, not only which SLAP
quadrant to use for the local MAC address configuration, but also quadrant to use for the local MAC address configuration, but also
when to perform a change of address (e.g., it might be needed to when to perform a change of address (e.g., it might be needed to
change address several times). This information includes, but it is change address several times). This information includes, but it is
not limited to: not limited to:
skipping to change at page 7, line 46 skipping to change at page 8, line 6
o Trusted network? Y/N. o Trusted network? Y/N.
o First time visited network? Y/N. o First time visited network? Y/N.
o Network geographical location. o Network geographical location.
o Mobility? Y/N. o Mobility? Y/N.
o OS network profile, including security/trust related parameters. o OS network profile, including security/trust related parameters.
Most modern OS keep metadata associated to the networks they can Most modern OSs keep metadata associated to the networks they can
attach to, as for example the level of trust the user or attach to, as for example the level of trust the user or
administrator assigns to the network. This information is used to administrator assigns to the network. This information is used to
configure how the device behaves in terms of advertising itself on configure how the device behaves in terms of advertising itself on
the network, firewall settings, etc. But this information can the network, firewall settings, etc. But this information can
also be used to decide whether to configure a local MAC address or also be used to decide whether to configure a local MAC address or
not, from which SLAP quadrant and how often. not, from which SLAP quadrant and how often.
o Triggers coming from applications regarding location privacy. An o Triggers coming from applications regarding location privacy. An
app might request to the OS to maximize location privacy (due to app might request to the OS to maximize location privacy (due to
the nature of the application) and this might mean the OS to force the nature of the application) and this might require that the OS
the use or change of a local MAC address. 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 This information can be used by the device to select the SLAP
quadrant. For example, if the device is moving around (e.g., while 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 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 might change access point several times, and therefore it is best to
minimize the chances of address collision, using the SAI or AAI minimize the chances of address collision, using the SAI or AAI
quadrants. If the device is not moving and attached to a trusted 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 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 quadrant. These are just some examples of how to use this
information to select the quadrant. information to select the quadrant.
skipping to change at page 8, line 35 skipping to change at page 8, line 43
enhancement to make it harder to track the user location. enhancement to make it harder to track the user location.
Last, if we consider the data center scenario, a hypervisor might Last, if we consider the data center scenario, a hypervisor might
request local MAC addresses to be assigned to virtual machines. As request local MAC addresses to be assigned to virtual machines. As
in the previous scenarios, the hypervisor might select the preferred in the previous scenarios, the hypervisor might select the preferred
SLAP quadrant using information provided by the cloud management SLAP quadrant using information provided by the cloud management
system (CMS) or virtualization infrastructure manager (VIM) running system (CMS) or virtualization infrastructure manager (VIM) running
on top of the hypervisor. This information might include, but is not on top of the hypervisor. This information might include, but is not
limited to: limited to:
o Migratable/non-migratable VM. If the function implemented by the o Migratable VM. If the function implemented by the VM is subject
VM is subject to be moved to another physical server or not. This to be moved to another physical server or not. This has an impact
has an impact on the preference for the SLAP quadrant, as some on the preference for the SLAP quadrant, as some quadrants are
quadrants are better suited (e.g., ELI/SAI) for supporting better suited (e.g., ELI/SAI) for supporting migration in a large
migration in a large data center. data center.
o VM connectivity characteristics , e.g.,: standalone, part of a o VM connectivity characteristics , e.g.,: standalone, part of a
pool, part of a service graph/chain. If the connectivity pool, part of a service graph/chain. If the connectivity
characteristics of the VM are known, this can be used by the characteristics of the VM are known, this can be used by the
hypervisor to select the best SLAP quadrant. hypervisor to select the best SLAP quadrant.
4. DHCPv6 extensions 4. DHCPv6 extensions
4.1. Address assignment from the preferred SLAP quadrant indicated by
the client
We describe next the protocol operations for a client to select a 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 preferred SLAP quadrant using the DHCPv6 signaling procedures
described in [I-D.ietf-dhc-mac-assign]. The signaling flow is shown described in [I-D.ietf-dhc-mac-assign]. The signaling flow is shown
in Figure 3. in Figure 3.
+--------+ +--------+ +--------+ +--------+
| DHCPv6 | | DHCPv6 | | DHCPv6 | | DHCPv6 |
| client | | server | | client | | server |
+--------+ +--------+ +--------+ +--------+
| | | |
+-------1. Solicit(IA_LL(QUAD))------->| +-------1. Solicit(IA_LL(QUAD))------->|
skipping to change at page 9, line 40 skipping to change at page 9, line 43
| | | |
|<-----6. Reply(IA_LL(LLADDR))---------+ |<-----6. Reply(IA_LL(LLADDR))---------+
| | | |
Figure 3: DHCPv6 signaling flow (client-server) Figure 3: DHCPv6 signaling flow (client-server)
1. Link-layer addresses (i.e., MAC addresses) are assigned in 1. Link-layer addresses (i.e., MAC addresses) are assigned in
blocks. The smallest block is a single address. To request an blocks. The smallest block is a single address. To request an
assignment, the client sends a Solicit message with a IA_LL assignment, the client sends a Solicit message with a IA_LL
option in the message. The IA_LL option MUST contain a LLADDR option in the message. The IA_LL option MUST contain a LLADDR
option. In order to indicate the preferred SLAP quadrant, the option. In order to indicate the preferred SLAP quadrant(s), the
IA_LL option includes the new OPTION_QUAD option in the IA-LL- IA_LL option includes the new OPTION_QUAD option(s) in the IA-LL-
option field (with the LLAADR option). option field (with the LLAADR option).
2. The server, upon receiving a IA_LL option, inspects its content 2. The server, upon receiving a IA_LL option, inspects its content
and may offer an address or addresses for each LLADDR option and may offer an address or addresses for each LLADDR option
according to its policy. The server sends back an Advertise according to its policy. The server sends back an Advertise
message with an IA_LL option containing an LLADDR option that message with an IA_LL option containing an LLADDR option that
specifies the addresses being offered. If the server supports specifies the addresses being offered. If the server supports
the new QUAD IA-LL-option, and manages a block of addresses the new QUAD IA-LL-option, and manages a block of addresses
belonging to the requested quadrant, the addresses being offered belonging to the requested quadrant, the addresses being offered
SHOULD belong to the requested quadrant. If the server does not SHOULD belong to the requested quadrant. If the server does not
have addresses from the requested quadrant, it MUST return the have addresses from the requested quadrant, it MUST return the
IA_LL option containing a Status Code option with status set to IA_LL option containing a Status Code option with status set to
NoQuadAvail. NoQuadAvail (IANA-2).
3. The client waits for available servers to send Advertise 3. The client waits for available servers to send Advertise
responses and picks one server as defined in Section 18.2.9 of responses and picks one server as defined in Section 18.2.9 of
[RFC8415]. The client then sends a Request message that includes [RFC8415]. The client then sends a Request message that includes
the IA_LL container option with the LLADDR option copied from the the IA_LL container option with the LLADDR option copied from the
Advertise message sent by the chosen server. It includes the Advertise message sent by the chosen server. It includes the
preferred SLAP quadrant in the new QUAD IA-LL-option. preferred SLAP quadrant(s) in the new QUAD IA-LL-option.
4. Upon reception of a Request message with IA_LL container option, 4. Upon reception of a Request message with IA_LL container option,
the server assigns requested addresses. The server MAY alter the the server assigns requested addresses. The server MAY alter the
allocation at this time. It then generates and sends a Reply allocation at this time. It then generates and sends a Reply
message back to the client. Upon receiving a Reply message, the message back to the client. Upon receiving a Reply message, the
client parses the IA_LL container option and may start using all client parses the IA_LL container option and may start using all
provided addresses. Note that a client that has included a Rapid provided addresses. Note that a client that has included a Rapid
Commit option in the Solicit, may receive a Reply in response to Commit option in the Solicit, may receive a Reply in response to
the Solicit and skip the Advertise and Request steps above the Solicit and skip the Advertise and Request steps above
(following standard DHCPv6 procedures). (following standard DHCPv6 procedures).
5. When the assigned addresses are about to expire, the client sends 5. When the assigned addresses are about to expire, the client sends
a Renew message. It includes the preferred SLAP quadrant in the a Renew message. It includes the preferred SLAP quadrant(s) in
new QUAD IA-LL-option, so in case the server is unable to extend the new QUAD IA-LL-option, so in case the server is unable to
the lifetime on the existing address(es), the preferred quadrant extend the lifetime on the existing address(es), the preferred
is known for the allocation of any "new" addresses. quadrants are known for the allocation of any "new" addresses.
6. The server responds with a Reply message, including an LLADDR 6. The server responds with a Reply message, including an LLADDR
option with extended lifetime. option with extended lifetime.
4.2. Address assignment from the SLAP quadrant indicated by the relay 4.2. Address Assignment from the SLAP Quadrant Indicated by the Relay
We describe next the protocol operations for a relay to select a Next, we describe the protocol operations for a relay to select a
preferred SLAP quadrant using the DHCPv6 signaling procedures preferred SLAP quadrant using the DHCPv6 signaling procedures
described in [I-D.ietf-dhc-mac-assign]. This is useful when a DHCPv6 described in [I-D.ietf-dhc-mac-assign]. This is useful when a DHCPv6
server is operating over a large infrastructure split in different server is operating over a large infrastructure split in different
network regions, where each region might have different requirements. network regions, where each region might have different requirements.
The signaling flow is shown in Figure 4. The signaling flow is shown in Figure 4.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| DHCPv6 | | DHCPv6 | | DHCPv6 | | DHCPv6 | | DHCPv6 | | DHCPv6 |
| client | | relay | | server | | client | | relay | | server |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | |
+-----1. Solicit(IA_LL)----->| | +-----1. Solicit(IA_LL)----->| |
| +----2. Relay-forw | | +----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-forw | | +-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-forw | | |--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)--+ |
| | | | | |
Figure 4: DHCPv6 signaling flow (client-relay-server) Figure 4: DHCPv6 signaling flow (client-relay-server)
1. Link-layer addresses (i.e., MAC addresses) are assigned in 1. Link-layer addresses (i.e., MAC addresses) are assigned in
blocks. The smallest block is a single address. To request an blocks. The smallest block is a single address. To request an
assignment, the client sends a Solicit message with a IA_LL assignment, the client sends a Solicit message with a IA_LL
option in the message. The IA_LL option MUST contain a LLADDR option in the message. The IA_LL option MUST contain a LLADDR
option. option.
2. The DHCP relay receives the Solicit message and encapsulates it 2. The DHCP relay receives the Solicit message and encapsulates it
in a Relay-forw message. The relay, based on local knowledge in a Relay-forward message. The relay, based on local knowledge
and policies, includes in the Relay-Forw message the QUAD option and policies, includes in the Relay-forward message the QUAD
with the preferred quadrant. The relay might know which option with the preferred quadrant. The relay might know which
quadrant to request based on local configuration (e.g., the quadrant to request based on local configuration (e.g., the
served network contains IoT devices only, thus requiring ELI/ served network contains IoT devices only, thus requiring ELI/
SAI) or other means such as based on analyzing the Solicit SAI) or other means such as based on analyzing the Solicit
message from the client. message from the client. Note that if the client is sending
multiple instances of the IA_LL in the same message, the DHCP
relay MUST include a single QUAD option, that applies to all of
the IA_LLs in the client's message.
3. The server, upon receiving the forwarded Solicit message 3. The server, upon receiving the forwarded Solicit message
including a IA_LL option, inspects its content and decide may including a IA_LL option, inspects its content and decide may
offer an address or addresses for each LLADDR option according offer an address or addresses for each LLADDR option according
to its policy. The server sends back an Advertise message with to its policy. The server sends back an Advertise message with
an IA_LL option containing an LLADDR option that specifies the an IA_LL option containing an LLADDR option that specifies the
addresses being offered. This message is sent to the Relay in a addresses being offered. This message is sent to the Relay in a
Relay-reply message. If the server supports the semantics of Relay-reply message. If the server supports the semantics of
the preferred quadrant included in the QUAD option, and manages the preferred quadrant included in the QUAD option, and manages
a block of addresses belonging to the requested quadrant, then a block of addresses belonging to the requested quadrant, then
the addresses being offered SHOULD belong to the requested the addresses being offered SHOULD belong to the requested
quadrant. quadrant. Note that if the client is sending multiple instances
of the IA_LL in the same message, a single QUAD option is
supported, applying to all of the IA_LLs in the client's
message.
4. The relay sends the received Advertise message to the client. 4. The relay sends the received Advertise message to the client.
5. The client waits for available servers to send Advertise 5. The client waits for available servers to send Advertise
responses and picks one server as defined in Section 18.2.9 of responses and picks one server as defined in Section 18.2.9 of
[RFC8415]. The client then sends a Request message that [RFC8415]. The client then sends a Request message that
includes the IA_LL container option with the LLADDR option includes the IA_LL container option with the LLADDR option
copied from the Advertise message sent by the chosen server. copied from the Advertise message sent by the chosen server.
6. The relay forwards the received Request in a Relay-forw message. 6. The relay forwards the received Request in a Relay-forward
It adds in the Relay-forw a QUAD IA-LL-option with the preferred message. It adds in the Relay-forward a QUAD IA-LL-option with
quadrant. the preferred quadrant.
7. Upon reception of the forwarded Request message with IA_LL 7. Upon reception of the forwarded Request message with IA_LL
container option, the server assigns requested addresses. The container option, the server assigns requested addresses. The
server MAY alter the allocation at this time. It then generates server MAY alter the allocation at this time. It then generates
and sends a Reply message, in a Relay-reply back to the relay. 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 8. Upon receiving a Reply message, the client parses the IA_LL
container option and may start using all provided addresses. container option and may start using all provided addresses.
9. When the assigned addresses are about to expire, the client 9. When the assigned addresses are about to expire, the client
sends a Renew message. sends a Renew message.
10. This message is forwarded by the Relay in a Relay-forw message, 10. This message is forwarded by the Relay in a Relay-forward
including a QUAD IA-LL-option with the preferred quadrant. message, including a QUAD IA-LL-option with the preferred
quadrant.
11. The server responds with a Reply message, including an LLADDR 11. The server responds with a Reply message, including an LLADDR
option with extended lifetime. This message is sent in a Relay- option with extended lifetime. This message is sent in a Relay-
Reply message. reply message.
12. The relay sends the Reply message back to the client. 12. The relay sends the Reply message back to the client.
5. DHCPv6 options definitions If a client provides a QUAD IA-LL-option and the relay agent is still
configured to add its preference value, the server SHOULD follow what
is administratively configured in a QUAD_RELAY_PREF internal
variable. If the value is set to 1, then the realy provided
preference overrides what the client has provided, while if the
variable is set to 0, then the client's provided preference is
considered. It is RECOMMENDED that QUAD_REALY_PREF is set to 1 at
the server.
5. DHCPv6 Options Definitions
5.1. Quad (IA-LL) option 5.1. Quad (IA-LL) option
The QUAD option is used to specify the preferences for the selected The QUAD option is used to specify the preferences for the selected
quadrants within an IA_LL. The option must either be encapsulated in 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-Forw message the IA-LL-options field of an IA_LL option or in a Relay-forward
in the options field. It MAY also be in a Relay-Reply if the QUAD message.
option code was specified in a ERO option [RFC4994].
The format of the QUAD option is: The format of the QUAD option is:
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_QUAD | option-len | | OPTION_QUAD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| quadrant-1 | pref-1 | quadrant-2 | pref-2 | | quadrant-1 | pref-1 | quadrant-2 | pref-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Quad Option Format Figure 5: Quad Option Format
option-code OPTION_QUAD (value to be assigned by IANA). option-code OPTION_QUAD (IANA-1).
option-len 2 * number of included (quadrant, preference). option-len 2 * number of included (quadrant, preference).
quadrant-n Identifier of the quadrant (0: AAI, 1: ELI: 2, SAI: quadrant-n Identifier of the quadrant (0: AAI, 1: ELI: 2, SAI:
3, 4: reserved). 3, 4: reserved). Each quadrant MUST only appear once
at most in the option. If an option includes more
than one occurence of the same quadrant, only the
first occurence is processed and the rest MUST be
ignored by the server.
pref-n Preference associated to quadrant-n. pref-n Preference associated to quadrant-n. A higher value
means a more preferred quadrant. If a same
preference value is used for more than one quadrant,
it is left to the server implementation which
quadrant should be preferred (if the server can
assign addresses from all of some of the quadrants
with the same assigned preference).
If the client or relay agent provide the OPTION_QUAD, the server uses
the quadrant-n/pref-n values to order the selection of the quadrants.
If the server can provide an assignment from one 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).
Client and relay agent MUST NOT place the same quadrant value into
the option more than once; however servers should be capable of
dealing with this by using the more preferred instance (as it
requires no special handling).
If the same preference value is used for more than one quadrant, the
behavior as to which is more preferred is random.
6. IANA Considerations 6. IANA Considerations
TBD. IANA is kindly requested to assign new values for option QUAD (IANA-
1) and NoQuadAvail error code (IANA-2) and to update the registry
maintained at http://www.iana.org/assignments/dhcpv6-parameters.
7. Security Considerations 7. Security Considerations
TBD. 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 8. Acknowledgments
The authors would like to thank Bernie Volz for his very valuable The authors would like to thank Bernie Volz for his very valuable
comments on this document. comments on this document. We also want to thank Ian Farrer for his
very detailed and helpful review.
The work in this draft will be further developed and explored under The work in this draft will be further developed and explored under
the framework of the H2020 5G-CORAL project (Grant 761586). the framework of the H2020 5G-CORAL project (Grant 761586).
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski,
"DHCPv6 Relay Agent Echo Request Option", RFC 4994,
DOI 10.17487/RFC4994, September 2007,
<https://www.rfc-editor.org/info/rfc4994>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-dhc-mac-assign] [I-D.ietf-dhc-mac-assign]
Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer
Addresses Assignment Mechanism for DHCPv6", draft-ietf- Addresses Assignment Mechanism for DHCPv6", draft-ietf-
dhc-mac-assign-00 (work in progress), April 2019. dhc-mac-assign-02 (work in progress), January 2020.
[IEEEStd802c-2017] [IEEEStd802c-2017]
IEEE Computer Society, "IEEE Standard for Local and IEEE Computer Society, "IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture, Metropolitan Area Networks: Overview and Architecture,
Amendment 2: Local Medium Access Control (MAC) Address Amendment 2: Local Medium Access Control (MAC) Address
Usage, IEEE Std 802c-2017". Usage, IEEE Std 802c-2017".
Authors' Addresses Authors' Addresses
Carlos J. Bernardos Carlos J. Bernardos
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30 Av. Universidad, 30
Leganes, Madrid 28911 Leganes, Madrid 28911
Spain Spain
Phone: +34 91624 6236 Phone: +34 91624 6236
Email: cjbc@it.uc3m.es Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/ URI: http://www.it.uc3m.es/cjbc/
 End of changes. 46 change blocks. 
97 lines changed or deleted 162 lines changed or added

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