draft-ietf-dhc-slap-quadrant-07.txt   draft-ietf-dhc-slap-quadrant-08.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: October 16, 2020 InterDigital Expires: November 14, 2020 InterDigital
April 14, 2020 May 13, 2020
SLAP quadrant selection options for DHCPv6 SLAP quadrant selection options for DHCPv6
draft-ietf-dhc-slap-quadrant-07 draft-ietf-dhc-slap-quadrant-08
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.
The IEEE is working on mechanisms to allocate addresses in the one of The IEEE is working on mechanisms to allocate addresses in the one of
these quadrants (IEEE 802.1CQ). There is work also in the IETF on these quadrants (IEEE 802.1CQ). There is work also in the IETF on
specifying a new mechanism that extends DHCPv6 operation to handle specifying a new mechanism that extends DHCPv6 operation to handle
the local MAC address assignments. In this document, we complement the local MAC address assignments. We complement this work by
this ongoing IETF work by defining a mechanism to allow choosing the defining a mechanism to allow choosing the SLAP quadrant to use in
SLAP quadrant to use in the allocation of the MAC address to the the allocation of the MAC address to the requesting device/client.
requesting device/client.
This document proposes extensions to DHCPv6 protocols to enable a This document proposes extensions to DHCPv6 protocols to enable a
DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant
to the server, so that the server allocates the MAC address to the to the server, so that the server allocates the MAC addresses to the
given client out of the quadrant requested by relay or client. A new given client out of the quadrant requested by relay or client. A new
DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this
purpose. purpose.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 16, 2020. This Internet-Draft will expire on November 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Quadrant Selection Mechanisms . . . . . . . . . . . . . . . . 7 3. Quadrant Selection Mechanisms examples . . . . . . . . . . . 7
4. DHCPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 the Relay . . . . . . . . . . . . . . . . . . . . . . . . 11
5. DHCPv6 Options Definitions . . . . . . . . . . . . . . . . . 14 5. DHCPv6 Options Definitions . . . . . . . . . . . . . . . . . 14
5.1. Quad (IA_LL) option . . . . . . . . . . . . . . . . . . . 14 5.1. Quad (IA_LL) option . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 3, line 24 skipping to change at page 3, line 24
assigned based on a protocol specified in an IEEE 802 standard. assigned based on a protocol specified in an IEEE 802 standard.
For 48-bit MAC addresses, 44 bits are available. Multiple For 48-bit MAC addresses, 44 bits are available. Multiple
protocols for assigning SAIs may be specified in IEEE standards. protocols for assigning SAIs may be specified in IEEE standards.
Coexistence of multiple protocols may be supported by limiting the Coexistence of multiple protocols may be supported by limiting the
subspace available for assignment by each protocol. subspace available for assignment by each protocol.
o Quadrant "Administratively Assigned Identifier" (AAI) MAC o Quadrant "Administratively Assigned Identifier" (AAI) MAC
addresses are assigned locally by an administrator. Multicast addresses are assigned locally by an administrator. Multicast
IPv6 packets use a destination address starting in 33-33 and this IPv6 packets use a destination address starting in 33-33 and this
falls within this space and therefore should not be used to avoid falls within this space and therefore should not be used to avoid
conflict with IPv6 multicast addresses. For 48-bit MAC addresses, conflict with the MAC addresses used for use with IPv6 multicast
44 bits are available. addresses. For 48-bit MAC addresses, 44 bits are available.
o Quadrant "Reserved for future use" where MAC addresses may be o Quadrant "Reserved for future use" where MAC addresses may be
assigned using new methods yet to be defined, or by an assigned using new methods yet to be defined, or by an
administrator like in the AAI quadrant. administrator like in the AAI quadrant. For 48-bit MAC addresses,
44 bits would be available.
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)
Figure 1: IEEE 48-bit MAC address structure Figure 1: IEEE 48-bit MAC address structure
skipping to change at page 4, line 24 skipping to change at page 4, line 24
+----------+-------+-------+-----------------------+----------------+ +----------+-------+-------+-----------------------+----------------+
Figure 2: SLAP quadrants Figure 2: SLAP quadrants
1.1. Problem statement 1.1. Problem statement
The IEEE is working on mechanisms to allocate addresses in the SAI The IEEE is working on mechanisms to allocate addresses in the SAI
quadrant (IEEE 802.1CQ project). There is also ongoing work in the quadrant (IEEE 802.1CQ project). There is also ongoing work in the
IETF [I-D.ietf-dhc-mac-assign] specifying a new mechanism that IETF [I-D.ietf-dhc-mac-assign] specifying a new mechanism that
extends DHCPv6 operation to handle the local MAC address assignments. extends DHCPv6 operation to handle the local MAC address assignments.
In this document, we complement ongoing IETF work with mechanisms to We complement this work by defining a mechanism to allow choosing the
allow choosing the SLAP quadrant to use in the allocation of the MAC SLAP quadrant to use in the allocation of the MAC address to the
address to the requesting device/client. This document proposes requesting device/client. This document proposes extensions to
extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to
relay to indicate a preferred SLAP quadrant to the server, so that indicate a preferred SLAP quadrant to the server, so that the server
the server allocates the MAC address to the given client out of the allocates the MAC address to the given client out of the quadrant
quadrant requested by relay or client. requested by relay or client.
In the following, we describe two application scenarios where a need In the following, we describe two application scenarios where a need
arises to assign local MAC addresses according to preferred SLAP arises to assign local MAC addresses according to preferred SLAP
quadrants. quadrants.
1.1.1. WiFi devices 1.1.1. WiFi devices
Today, most WiFi devices come with interfaces that have a "burned in" Today, most WiFi devices come with interfaces that have a "burned in"
MAC address, allocated from the universal address space using a MAC address, allocated from the universal address space using a
24-bit Organizationally Unique Identifier (OUI, assigned to IEEE 802 24-bit Organizationally Unique Identifier (OUI, assigned to IEEE 802
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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 examples
The following section describes some examples of how the quadrant The following section describes some examples of how the quadrant
preference mechanisms could be used. 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
skipping to change at page 7, line 40 skipping to change at page 7, line 40
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 considerations that the device vendor/administrator The previous parameters are considerations that the device vendor/
may wish to use when defining the IoT device's MAC address request administrator may wish to use when defining the IoT device's
policy (i.e., how to select a given SLAP quadrant). IoT devices are MAC address request policy (i.e., how to select a given SLAP
typically very resource constrained, so there may only be simple quadrant). IoT devices are typically very resource constrained, so
decision making process based on pre-configured preferences. 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 14, line 32 skipping to change at page 14, line 32
The client MAY check if the received MAC address belongs to a The client MAY check if the received MAC address belongs to a
quadrant it is willing to use/configure, and MAY decide based on that quadrant it is willing to use/configure, and MAY decide based on that
whether to use configure the received address. whether to use configure the received address.
5. DHCPv6 Options Definitions 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-forward the IA_LL-options field of an IA_LL option or in a Relay-forward
message. message.
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_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Quad Option Format Figure 5: Quad Option Format
option-code OPTION_SLAP_QUAD (IANA-1). option-code OPTION_SLAP_QUAD (IANA-1).
option-len 2 * number of included (quadrant, preference). option-len 2 * number of included (quadrant, preference). A
2-byte field containing the total length of all
(quadrant, preference) pairs included in the option.
quadrant-n Identifier of the quadrant (0: AAI, 1: ELI, 2: quadrant-n Identifier of the quadrant (0: AAI, 1: ELI, 2:
Reserved, 3: SAI). Each quadrant MUST only appear Reserved, 3: SAI). Each quadrant MUST only appear
once at most in the option. once at most in the option. A 1-byte field.
pref-n Preference associated to quadrant-n. A higher value pref-n Preference associated to quadrant-n. A higher value
means a more preferred quadrant. means a more preferred quadrant. A 1-byte field.
A quadrant identifier value MUST only appear at most once in the A quadrant identifier value MUST only appear at most once in the
option. If an option includes more than one occurrence of the same option. If an option includes more than one occurrence of the same
quadrant identifier, only the first occurence is processed and the quadrant identifier, only the first occurence is processed and the
rest MUST be ignored by the server. rest MUST be ignored by the server.
If the same preference value is used for more than one quadrant, it If the same preference value is used for more than one quadrant, the
is left to the server implementation which quadrant should be server MAY select which quadrant should be preferred (if the server
preferred (if the server can assign addresses from all or some of the can assign addresses from all or some of the quadrants with the same
quadrants with the same assigned preference). Note that a quadrant - assigned preference). Note that a quadrant - preference tuple is
preference tuple is used in this option (instead of using a list of used in this option (instead of using a list of quadrants ordered by
quadrants ordered by preference) to support the case whereby a client preference) to support the case whereby a client really has no
really has no preference between two or three quadrants, leaving the preference between two or three quadrants, leaving the decision to
decision to the server. the server.
If the client or relay agent provide the OPTION_SLAP_QUAD, the server If the client or relay agent provide the OPTION_SLAP_QUAD, the server
uses the quadrant-n/pref-n values to order the selection of the MUST use the quadrant-n/pref-n values to order the selection of the
quadrants. If the server can provide an assignment from one of the quadrants. If the server can provide an assignment from one of the
specified quadrants, it should proceed with the assignment. If the specified quadrants, it SHOULD proceed with the assignment. If the
server cannot provide an assignment from one of the specified server cannot provide an assignment from one of the specified
quadrant-n fields, it MUST NOT assign any addresses and return a quadrant-n fields, it MUST NOT assign any addresses and return a
status of NoQuadAvail (IANA-2) in the IA_LL Option. status of NoQuadAvail (IANA-2) in the IA_LL Option.
There is no requirement that the client or relay agent order the There is no requirement that the client or relay agent order the
quadrant/pref values in any specific order; hence servers MUST NOT quadrant/pref values in any specific order; hence servers MUST NOT
assume that quadrant-1/pref-1 have the highest preference (except if assume that quadrant-1/pref-1 have the highest preference (except if
there is only 1 set of values). there is only 1 set of values).
6. IANA Considerations 6. IANA Considerations
skipping to change at page 16, line 31 skipping to change at page 16, line 31
See [RFC8415] for the DHCPv6 security considerations. See [RFC8200] See [RFC8415] for the DHCPv6 security considerations. See [RFC8200]
for the IPv6 security considerations. for the IPv6 security considerations.
See also [I-D.ietf-dhc-mac-assign] for security considerations See also [I-D.ietf-dhc-mac-assign] for security considerations
regarding link-layer address assignments using DHCP. 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. We also want to thank Ian Farrer and comments on this document. We also want to thank Ian Farrer, Tomek
Tomek Mrugalski for their very detailed and helpful reviews. Mrugalski and Eric Vyncke for their very detailed and helpful
reviews.
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 5Growth (Grant 856709) and 5G-DIVE the framework of the H2020 5Growth (Grant 856709) and 5G-DIVE
projects (Grant 859881). projects (Grant 859881).
9. References 9. References
9.1. Normative References 9.1. Normative 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-05 (work in progress), March 2020. dhc-mac-assign-06 (work in progress), May 2020.
[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>.
[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>.
 End of changes. 21 change blocks. 
44 lines changed or deleted 48 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/