draft-ietf-dhc-slap-quadrant-08.txt   draft-ietf-dhc-slap-quadrant-09.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: November 14, 2020 InterDigital Expires: November 28, 2020 InterDigital
May 13, 2020 May 27, 2020
SLAP quadrant selection options for DHCPv6 SLAP quadrant selection options for DHCPv6
draft-ietf-dhc-slap-quadrant-08 draft-ietf-dhc-slap-quadrant-09
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 November 14, 2020. This Internet-Draft will expire on November 28, 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 47 skipping to change at page 2, line 47
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 Universal/
set to 1). Recently, the IEEE has been working on a new Local -- U/L -- bit is set to 1). Recently, the IEEE has been
specification (IEEE 802c [IEEEStd802c-2017]) which defines a new working on a new specification (IEEE 802c [IEEEStd802c-2017]) which
"optional Structured Local Address Plan" (SLAP) that specifies defines a new "optional Structured Local Address Plan" (SLAP) that
different assignment approaches in four specified regions of the specifies different assignment approaches in four specified regions
local MAC address space. These four regions, called SLAP quadrants, of the local MAC address space. These four regions, called SLAP
are briefly described below (see Figure 1 and Figure 2 for details): quadrants, are briefly described below (see Figure 1 and Figure 2 for
details):
o Quadrant "Extended Local Identifier" (ELI) MAC addresses are o Quadrant "Extended Local Identifier" (ELI) MAC addresses are
assigned based on a Company ID (CID), which takes 24-bits, leaving assigned based on a Company ID (CID), which takes 24-bits, leaving
the remaining 24-bits for the locally assigned address for each the remaining 24-bits for the locally assigned address for each
CID for unicast (M-bit = 0) and also for multicast (M-bit = 1). CID for unicast (M-bit = 0) and also for multicast (M-bit = 1).
The CID is assigned by the IEEE Registration Authority (RA). The CID is assigned by the IEEE Registration Authority (RA).
o Quadrant "Standard Assigned Identifier" (SAI) MAC addresses are o Quadrant "Standard Assigned Identifier" (SAI) MAC addresses are
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
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]. functionality as described in [RFC8415].
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 7, line 29 skipping to change at page 7, line 29
industrial or rural ones, where thousands of devices might co- industrial or rural ones, where thousands of devices might co-
exist, the IoT can decide to use the ELI or SAI quadrants. exist, the IoT can decide to use the ELI or SAI quadrants.
o Mobility: if the IoT device can move, then it might prefer to o Mobility: if the IoT device can move, then it might prefer to
select the SAI or AAI quadrants to minimize address collisions select the SAI or AAI quadrants to minimize address collisions
when moving to another network. If the device is known to remain when moving to another network. If the device is known to remain
fixed, then the ELI is probably the most suitable one to use. fixed, then the ELI is probably the most suitable one to use.
o Managed/unmanaged: depending on whether the IoT device is managed o Managed/unmanaged: depending on whether the IoT device is managed
during its lifetime or cannot be re-configured, the selected during its lifetime or cannot be re-configured, the selected
quadrant might be different. For example, it can be managed, this quadrant might be different. For example, if it can be managed,
means that network topology changes might occur during its this 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 parameters are considerations that the device vendor/ The previous parameters are considerations that the device vendor/
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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. The client is expected to periodically renew the link-layer
a Renew message. It includes the preferred SLAP quadrant(s) in addresses as governed by T1 and T2 timers. This mechanism can be
the new QUAD IA_LL-option, so in case the server is unable to administratively disabled by the server sending "infinity" as the
extend the lifetime on the existing address(es), the preferred T1 and T2 values (see Section 7.7 of [RFC8415]). When the
quadrants are known for the allocation of any "new" addresses. assigned addresses are about to expire, the client sends a Renew
message. It includes the preferred SLAP quadrant(s) in the new
QUAD IA_LL-option, so in case the server is unable to extend the
lifetime on the existing address(es), the preferred quadrants are
known for the allocation of any "new" (i.e., different)
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.
The client SHOULD check if the received MAC address comes from one of The client SHOULD check if the received MAC address comes from one of
the requested quadrants. Otherwise, the client SHOULD NOT configure the requested quadrants. Otherwise, the client SHOULD NOT configure
the obtained address. It MAY repeat the process selecting a the obtained address. It MAY repeat the process selecting a
different DHCP server. different DHCP server.
4.2. Address Assignment from the SLAP Quadrant Indicated by the Relay 4.2. Address Assignment from the SLAP Quadrant Indicated by the Relay
skipping to change at page 13, line 47 skipping to change at page 13, line 47
the preferred 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. The client is expected to periodically renew the link-layer
sends a Renew message. addresses as governed by T1 and T2 timers. This mechanism can
be administratively disabled by the server sending "infinity" as
the T1 and T2 values (see Section 7.7 of [RFC8415]). When the
assigned addresses are about to expire, the client sends a Renew
message.
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.
skipping to change at page 16, line 32 skipping to change at page 16, line 32
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, Tomek comments on this document. We also want to thank Ian Farrer, Tomek
Mrugalski and Eric Vyncke for their very detailed and helpful Mrugalski, Eric Vyncke, Tatuya Jinmei and Carl Wallace for their very
reviews. 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]
 End of changes. 9 change blocks. 
23 lines changed or deleted 33 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/