draft-ietf-dhc-slap-quadrant-04.txt   draft-ietf-dhc-slap-quadrant-05.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: August 31, 2020 InterDigital Expires: September 8, 2020 InterDigital
February 28, 2020 March 7, 2020
SLAP quadrant selection options for DHCPv6 SLAP quadrant selection options for DHCPv6
draft-ietf-dhc-slap-quadrant-04 draft-ietf-dhc-slap-quadrant-05
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 32 skipping to change at page 1, line 32
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. In this document, we complement
this ongoing IETF work by defining a mechanism to allow choosing the this ongoing IETF work by defining a mechanism to allow choosing the
SLAP quadrant to use in the allocation of the MAC address to the SLAP quadrant to use in 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 address to the
given client out of the quadrant requested by relay or client. given client out of the quadrant requested by relay or client. A new
DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this
purpose.
Status of This Memo 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 September 8, 2020.
This Internet-Draft will expire on August 31, 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 26 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Quadrant Selection Mechanisms . . . . . . . . . . . . . . . . 6 3. Quadrant Selection Mechanisms . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 13 5. DHCPv6 Options Definitions . . . . . . . . . . . . . . . . . 14
5.1. Quad (IA_LL) option . . . . . . . . . . . . . . . . . . . 13 5.1. Quad (IA_LL) option . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 9, line 41 skipping to change at page 10, line 7
| | | |
+---5. Renew(IA_LL(LLADDR,QUAD))------>| +---5. Renew(IA_LL(LLADDR,QUAD))------>|
| | | |
|<-----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 an 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(s), the 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 includes the new OPTION_SLAP_QUAD option in the
IA_LL-option field (with the LLAADR option). IA_LL-option field (with the LLAADR option).
2. The server, upon receiving a IA_LL option, inspects its content 2. The server, upon receiving an 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(s), the addresses being belonging to the requested quadrant(s), the addresses being
offered MUST belong to the requested quadrant(s). If the server offered MUST belong to the requested quadrant(s). If the server
does not have a configured address pool matching the client's does not have a configured address pool matching the client's
request, it MUST return the IA_LL option containing a Status Code request, it MUST return the IA_LL option containing a Status Code
option with status set to NoQuadAvail (IANA-2). If the client option with status set to NoQuadAvail (IANA-2). If the client
skipping to change at page 11, line 51 skipping to change at page 12, line 42
| | | | | |
| |<---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 an 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-forward message. The relay, based on local knowledge in a Relay-forward message. The relay, based on local knowledge
and policies, includes in the Relay-forward message the QUAD and policies, includes in the Relay-forward message the QUAD
option 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. Note that if a client sends multiple SAI) or other means. Note that if a client sends multiple
instances of the IA_LLoption in the same message, the DHCP relay instances of the IA_LL option in the same message, the DHCP
MUST ONLY add a singleinstance of the QUAD option. The server relay MUST only add a single instance of the QUAD option.
SHOULD apply thecontents of the relay's supplied QUAD option for
all of theclient's IA_LLs, unless configured to do otherwise.
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 an 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(s), a block of addresses belonging to the requested quadrant(s),
then the addresses being offered SHOULD belong to the requested then the addresses being offered MUST belong to the requested
quadrant(s). Note that if the client is sending multiple quadrant(s). The server SHOULD apply the contents of the
instances of the IA_LL in the same message, a single QUAD option relay's supplied QUAD option for all of the client's IA_LLs,
is supported, applying to all of the IA_LLs in the client's unless configured to do otherwise.
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-forward 6. The relay forwards the received Request in a Relay-forward
skipping to change at page 13, line 24 skipping to change at page 14, line 10
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.
If a client provides a QUAD IA_LL-option and the relay agent is still 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 configured to add its preference value, the server SHOULD follow what
is administratively configured in a QUAD_RELAY_PREF internal is administratively configured in a QUAD_RELAY_PREF internal
variable. If the value is set to 1, then the realy provided variable. If the value is set to 1, the server is administratively
preference overrides what the client has provided, while if the configured to evaluate the client's supplied instance of
variable is set to 0, then the client's provided preference is OPTION_SLAP_QUAD and ignore the relay supplied instance. If the
considered. It is RECOMMENDED that QUAD_RELAY_PREF is set to 1 at variable is set to 0, then the server is administratively configured
the server. to evaluate the relay's provided preference and ignore the client
supplied instance. It is RECOMMENDED that QUAD_RELAY_PREF is set to
0 at the server.
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
skipping to change at page 14, line 29 skipping to change at page 15, line 8
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: 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.
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 quadrant value MUST only appear once at most in the option. If an A quadrant identifier value MUST only appear at most once in the
option includes more than one occurence of the same quadrant value, option. If an option includes more than one occurrence of the same
only the first occurence is processed and the rest MUST be ignored by quadrant identifier, only the first occurence is processed and the
the server. rest MUST be ignored by the server.
If a same preference value is used for more than one quadrant, it is If the same preference value is used for more than one quadrant, it
left to the server implementation which quadrant should be preferred is left to the server implementation which quadrant should be
(if the server can assign addresses from all of some of the quadrants preferred (if the server can assign addresses from all or some of the
with the same assigned preference). quadrants with the same assigned preference). Note that a quadrant -
preference tuple is used in this option (instead of using a list of
quadrants ordered by preference) to support the case whereby a client
really has no preference between two or three quadrants, leaving the
decision to the server.
If the client or relay agent provide the OPTION_SLAP_QUAD, the server 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 uses 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).
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).
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign the QUAD (IANA-1) option code from the IANA is requested to assign the QUAD (IANA-1) option code from the
DHCPv6 "Option Codes" registry maintained at DHCPv6 "Option Codes" registry maintained at
http://www.iana.org/assignments/dhcpv6-parameters and use the http://www.iana.org/assignments/dhcpv6-parameters and use the
following data when adding the option to the registry: following data when adding the option to the registry:
Value: IANA-1 Value: IANA-1
Description: OPTION_SLAP_QUAD Description: OPTION_SLAP_QUAD
Client ORO: No Client ORO: No
skipping to change at page 16, line 34 skipping to change at page 17, line 16
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-03 (work in progress), January 2020. dhc-mac-assign-04 (work in progress), March 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
 End of changes. 19 change blocks. 
46 lines changed or deleted 45 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/