draft-ietf-dhc-slap-quadrant-05.txt   draft-ietf-dhc-slap-quadrant-06.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 8, 2020 InterDigital Expires: September 17, 2020 InterDigital
March 7, 2020 March 16, 2020
SLAP quadrant selection options for DHCPv6 SLAP quadrant selection options for DHCPv6
draft-ietf-dhc-slap-quadrant-05 draft-ietf-dhc-slap-quadrant-06
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 8, 2020. This Internet-Draft will expire on September 17, 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 6, line 38 skipping to change at page 6, line 38
[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 relay A node that acts as an intermediary to deliver DHCP
messages between clients and servers. A relay, based messages between clients and servers. A relay, based
on local knowledge and policies, may include the on local knowledge and policies, may include the
preferred SLAP quadrant in a QUAD option sent to the preferred SLAP quadrant in a QUAD option sent to the
server. The relay implements basic DHCPv6 relay agent server. The relay implements basic DHCPv6 relay agent
functionality as described in in [RFC8415] and supports functionality as described in in [RFC8415].
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
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 an IA_LL option, inspects its content 2. The server, upon receiving a IA_LL option, inspects its contents.
and may offer an address or addresses for each LLADDR option For each of the entries in OPTION_SLAP_QUAD, in order of the
according to its policy. The server sends back an Advertise preference field (highest to lowest), the server checks if it has
message with an IA_LL option containing an LLADDR option that a configured MAC address pool matching the requested quadrant
specifies the addresses being offered. If the server supports identifier, and an available range of addresses of the requested
the new QUAD IA_LL-option, and manages a block of addresses size. If suitable addresses are found, the server sends back an
belonging to the requested quadrant(s), the addresses being Advertise message with an IA_LL option containing an LLADDR
offered MUST belong to the requested quadrant(s). If the server option that specifies the addresses being offered. If the server
does not have a configured address pool matching the client's supports the new QUAD IA_LL-option, and manages a block of
request, it MUST return the IA_LL option containing a Status Code addresses belonging to the requested quadrant(s), the addresses
option with status set to NoQuadAvail (IANA-2). If the client being offered MUST belong to the requested quadrant(s). If the
specified more than one SLAP quadrant, the server MUST only server does not have a configured address pool matching the
return a NoQuadAvail status code if no address pool(s) client's request, it MUST return the IA_LL option containing a
Status Code option with status set to NoQuadAvail (IANA-2). If
the client specified more than one SLAP quadrant, the server MUST
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
[RFC8415]. The client SHOULD NOT pick a server that does not [RFC8415]. The client SHOULD NOT pick a server that does not
advertise an address in the requested quadrant. The client then advertise an address in the requested quadrant. The client then
skipping to change at page 14, line 7 skipping to change at page 14, line 7
10. This message is forwarded by the Relay in a Relay-forward 10. This message is forwarded by the Relay in a Relay-forward
message, including a QUAD IA_LL-option with the preferred message, including a QUAD IA_LL-option with the preferred
quadrant. 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.
If a client provides a QUAD IA_LL-option and the relay agent is still The server SHOULD implement a configuration parameter to deal
configured to add its preference value, the server SHOULD follow what with the case where the client's DHCP message contains an instance of
is administratively configured in a QUAD_RELAY_PREF internal OPTION_SLAP_QUAD, and the relay adds a second instance in its relay-
variable. If the value is set to 1, the server is administratively forward message. This parameter configures the server to process
configured to evaluate the client's supplied instance of either the client's, or the relay's instance of option QUAD. It is
OPTION_SLAP_QUAD and ignore the relay supplied instance. If the RECOMMENDED that the default for such a parameter is to process the
variable is set to 0, then the server is administratively configured client's instance of the option.
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
 End of changes. 6 change blocks. 
30 lines changed or deleted 28 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/