draft-ietf-dhc-slap-quadrant-06.txt   draft-ietf-dhc-slap-quadrant-07.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: September 17, 2020 InterDigital Expires: October 16, 2020 InterDigital
March 16, 2020 April 14, 2020
SLAP quadrant selection options for DHCPv6 SLAP quadrant selection options for DHCPv6
draft-ietf-dhc-slap-quadrant-06 draft-ietf-dhc-slap-quadrant-07
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 2, line 4 skipping to change at page 2, line 4
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 17, 2020. This Internet-Draft will expire on October 16, 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 10, line 13 skipping to change at page 10, line 13
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 an 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 contents. 2. The server, upon receiving an IA_LL option, inspects its
For each of the entries in OPTION_SLAP_QUAD, in order of the contents. For each of the entries in OPTION_SLAP_QUAD, in order
preference field (highest to lowest), the server checks if it has of the preference field (highest to lowest), the server checks if
a configured MAC address pool matching the requested quadrant it has a configured MAC address pool matching the requested
identifier, and an available range of addresses of the requested quadrant identifier, and an available range of addresses of the
size. If suitable addresses are found, the server sends back an requested size. If suitable addresses are found, the server
Advertise message with an IA_LL option containing an LLADDR sends back an Advertise message with an IA_LL option containing
option that specifies the addresses being offered. If the server an LLADDR option that specifies the addresses being offered. If
supports the new QUAD IA_LL-option, and manages a block of the server supports the new QUAD IA_LL-option, and manages a
addresses belonging to the requested quadrant(s), the addresses block of addresses belonging to the requested quadrant(s), the
being offered MUST belong to the requested quadrant(s). If the addresses being offered MUST belong to the requested quadrant(s).
server does not have a configured address pool matching the If the server does not have a configured address pool matching
client's request, it MUST return the IA_LL option containing a the client's request, it MUST return the IA_LL option containing
Status Code option with status set to NoQuadAvail (IANA-2). If a Status Code option with status set to NoQuadAvail (IANA-2). If
the client specified more than one SLAP quadrant, the server MUST the client specified more than one SLAP quadrant, the server MUST
only return a NoQuadAvail status code if no address pool(s) only return a NoQuadAvail status code if no address pool(s)
configured at the server match any of the specified SLAP configured at the server match any of the specified SLAP
quadrants. If the server has a configured address pool of the quadrants. If the server has a configured address pool of the
correct quadrant, but no available addresses, it MUST return the correct quadrant, but no available addresses, 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
NoAddrsAvail. NoAddrsAvail.
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
skipping to change at page 13, line 7 skipping to change at page 13, line 7
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_LL option in the same message, the DHCP instances of the IA_LL option in the same message, the DHCP
relay MUST only add a single instance of the QUAD option. relay MUST only add a single instance of the QUAD option.
3. The server, upon receiving the forwarded Solicit message 3. Upon receiving a relayed message containing an IA_LL option, the
including an IA_LL option, inspects its content and decide may server inspects the contents for instances of OPTION_SLAP_QUAD
offer an address or addresses for each LLADDR option according in both the Relay Forward message and the client's message
to its policy. The server sends back an Advertise message with payload. Depending on the server's policy, the instance(s) of
an IA_LL option containing an LLADDR option that specifies the the option to process is selected. For each of the entries in
addresses being offered. This message is sent to the Relay in a OPTION_SLAP_QUAD, in order of the preference field (highest to
Relay-reply message. If the server supports the semantics of lowest), the server checks if it has a configured MAC address
the preferred quadrant included in the QUAD option, and manages pool matching the requested quadrant identifier, and an
a block of addresses belonging to the requested quadrant(s), available range of addresses of the requested size. If suitable
then the addresses being offered MUST belong to the requested addresses are found, the server sends back an Advertise message
quadrant(s). The server SHOULD apply the contents of the with an IA_LL option containing an LLADDR option that specifies
relay's supplied QUAD option for all of the client's IA_LLs, the addresses being offered. This message is sent to the Relay
in a Relay-reply message. If the server supports the semantics
of the preferred quadrant included in the QUAD option, and
manages a block of addresses belonging to the requested
quadrant(s), then the addresses being offered MUST belong to the
requested quadrant(s). The server SHOULD apply the contents of
the relay's supplied QUAD option for all of the client's IA_LLs,
unless configured to do otherwise. unless configured to do otherwise.
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.
skipping to change at page 16, line 31 skipping to change at page 16, line 42
Tomek Mrugalski for their very detailed and helpful reviews. Tomek Mrugalski 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]
Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer
Addresses Assignment Mechanism for DHCPv6", draft-ietf-
dhc-mac-assign-05 (work in progress), March 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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
skipping to change at page 17, line 7 skipping to change at page 17, line 27
<https://www.rfc-editor.org/info/rfc8200>. <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]
Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer
Addresses Assignment Mechanism for DHCPv6", draft-ietf-
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
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
 End of changes. 7 change blocks. 
35 lines changed or deleted 41 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/