draft-ietf-dhc-slap-quadrant-02.txt   draft-ietf-dhc-slap-quadrant-03.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: July 16, 2020 InterDigital Expires: August 31, 2020 InterDigital
January 13, 2020 February 28, 2020
SLAP quadrant selection options for DHCPv6 SLAP quadrant selection options for DHCPv6
draft-ietf-dhc-slap-quadrant-02 draft-ietf-dhc-slap-quadrant-03
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 49 skipping to change at page 1, line 49
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 July 16, 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 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Quadrant Selection Mechanisms . . . . . . . . . . . . . . . . 6 3. Quadrant Selection Mechanisms . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . . 10 the Relay . . . . . . . . . . . . . . . . . . . . . . . . 11
5. DHCPv6 Options Definitions . . . . . . . . . . . . . . . . . 13 5. DHCPv6 Options Definitions . . . . . . . . . . . . . . . . . 13
5.1. Quad (IA-LL) option . . . . . . . . . . . . . . . . . . . 13 5.1. Quad (IA-LL) option . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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
skipping to change at page 8, line 5 skipping to change at page 8, line 5
o Type of network the device is connected: public, work, home. o Type of network the device is connected: public, work, home.
o Trusted network? Y/N. o Trusted network? Y/N.
o First time visited network? Y/N. o First time visited network? Y/N.
o Network geographical location. o Network geographical location.
o Mobility? Y/N. o Mobility? Y/N.
o OS network profile, including security/trust related parameters. o Operating System (OS) network profile, including security/trust
Most modern OSs keep metadata associated to the networks they can related parameters. Most modern OSs keep metadata associated to
attach to, as for example the level of trust the user or the networks they can attach to, as for example the level of trust
administrator assigns to the network. This information is used to the user or administrator assigns to the network. This
configure how the device behaves in terms of advertising itself on information is used to configure how the device behaves in terms
the network, firewall settings, etc. But this information can of advertising itself on the network, firewall settings, etc. But
also be used to decide whether to configure a local MAC address or this information can also be used to decide whether to configure a
not, from which SLAP quadrant and how often. local MAC address or not, from which SLAP quadrant and how often.
o Triggers coming from applications regarding location privacy. An o Triggers coming from applications regarding location privacy. An
app might request to the OS to maximize location privacy (due to app might request to the OS to maximize location privacy (due to
the nature of the application) and this might require that the OS the nature of the application) and this might require that the OS
forces the use of a local MAC address, or that the local MAC forces the use of a local MAC address, or that the local MAC
address is changed. address is changed.
This information can be used by the device to select the SLAP This information can be used by the device to select the SLAP
quadrant. For example, if the device is moving around (e.g., while quadrant. For example, if the device is moving around (e.g., while
connected to a public network in an airport), it is likely that it connected to a public network in an airport), it is likely that it
skipping to change at page 9, line 5 skipping to change at page 9, line 5
to be moved to another physical server or not. This has an impact to be moved to another physical server or not. This has an impact
on the preference for the SLAP quadrant, as some quadrants are on the preference for the SLAP quadrant, as some quadrants are
better suited (e.g., ELI/SAI) for supporting migration in a large better suited (e.g., ELI/SAI) for supporting migration in a large
data center. data center.
o VM connectivity characteristics , e.g.,: standalone, part of a o VM connectivity characteristics , e.g.,: standalone, part of a
pool, part of a service graph/chain. If the connectivity pool, part of a service graph/chain. If the connectivity
characteristics of the VM are known, this can be used by the characteristics of the VM are known, this can be used by the
hypervisor to select the best SLAP quadrant. hypervisor to select the best SLAP quadrant.
4. DHCPv6 extensions 4. DHCPv6 Extensions
4.1. Address Assignment from the Preferred SLAP Quadrant Indicated by 4.1. Address Assignment from the Preferred SLAP Quadrant Indicated by
the Client the Client
Next, we describe the protocol operations for a client to select a Next, we describe the protocol operations for a client to select a
preferred SLAP quadrant using the DHCPv6 signaling procedures preferred SLAP quadrant using the DHCPv6 signaling procedures
described in [I-D.ietf-dhc-mac-assign]. The signaling flow is shown described in [I-D.ietf-dhc-mac-assign]. The signaling flow is shown
in Figure 3. in Figure 3.
+--------+ +--------+ +--------+ +--------+
skipping to change at page 9, line 44 skipping to change at page 9, line 44
|<-----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 a 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_QUAD option(s) in the IA-LL- IA_LL option includes the new OPTION_SLAP_QUAD option(s) in the
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 a 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, the addresses being offered belonging to the requested quadrant(s), the addresses being
SHOULD belong to the requested quadrant. If the server does not offered MUST belong to the requested quadrant(s). If the server
have addresses from the requested quadrant, it MUST return the does not have a configured address pool matching the client's
IA_LL option containing a Status Code option with status set to request, it MUST return the IA_LL option containing a Status Code
NoQuadAvail (IANA-2). 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 the address pool configured
at the server does not match any of the specified SLAP quadrants.
If the server has a configured address pool of the correct
quadrant, but no available addresses, it MUST return the IA_LL
option containing a Status Code option with status set to
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 then sends a Request message that includes [RFC8415]. The client then sends a Request message that includes
the IA_LL container option with the LLADDR option copied from the the IA_LL container option with the LLADDR option copied from the
Advertise message sent by the chosen server. It includes the Advertise message sent by the chosen server. It includes the
preferred SLAP quadrant(s) in the new QUAD IA-LL-option. preferred SLAP quadrant(s) in the new QUAD IA-LL-option.
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
skipping to change at page 10, line 36 skipping to change at page 10, line 43
5. When the assigned addresses are about to expire, the client sends 5. When the assigned addresses are about to expire, the client sends
a Renew message. It includes the preferred SLAP quadrant(s) in 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 the new QUAD IA-LL-option, so in case the server is unable to
extend the lifetime on the existing address(es), the preferred extend the lifetime on the existing address(es), the preferred
quadrants are known for the allocation of any "new" addresses. quadrants are known for the allocation of any "new" 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 requested quadrants. If not, SHOULD NOT configure the
obtained address. It MAY repeat the process selecting a 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
Next, we describe the protocol operations for a relay to select a Next, we describe the protocol operations for a relay to select a
preferred SLAP quadrant using the DHCPv6 signaling procedures preferred SLAP quadrant using the DHCPv6 signaling procedures
described in [I-D.ietf-dhc-mac-assign]. This is useful when a DHCPv6 described in [I-D.ietf-dhc-mac-assign]. This is useful when a DHCPv6
server is operating over a large infrastructure split in different server is operating over a large infrastructure split in different
network regions, where each region might have different requirements. network regions, where each region might have different requirements.
The signaling flow is shown in Figure 4. The signaling flow is shown in Figure 4.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
skipping to change at page 11, line 52 skipping to change at page 12, line 13
assignment, the client sends a Solicit message with a IA_LL assignment, the client sends a Solicit message with a 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 such as based on analyzing the Solicit SAI) or other means. Note that if a client sends multiple
message from the client. Note that if the client is sending instances of the IA_LLoption in the same message, the DHCP relay
multiple instances of the IA_LL in the same message, the DHCP MUST ONLY add a singleinstance of the QUAD option. The server
relay MUST include a single QUAD option, that applies to all of SHOULD apply thecontents of the relay's supplied QUAD option for
the IA_LLs in the client's message. 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 a 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, then a block of addresses belonging to the requested quadrant(s),
the addresses being offered SHOULD belong to the requested then the addresses being offered SHOULD belong to the requested
quadrant. Note that if the client is sending multiple instances quadrant(s). Note that if the client is sending multiple
of the IA_LL in the same message, a single QUAD option is instances of the IA_LL in the same message, a single QUAD option
supported, applying to all of the IA_LLs in the client's is supported, applying to all of the IA_LLs in the client's
message. 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.
skipping to change at page 13, line 17 skipping to change at page 13, line 27
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, then the realy provided
preference overrides what the client has provided, while if the preference overrides what the client has provided, while if the
variable is set to 0, then the client's provided preference is variable is set to 0, then the client's provided preference is
considered. It is RECOMMENDED that QUAD_REALY_PREF is set to 1 at considered. It is RECOMMENDED that QUAD_RELAY_PREF is set to 1 at
the server. the server.
The client SHOULD check if the received MAC address belongs to a
quadrant it is willing to use/configure. If not, SHOULD NOT
configure the obtained 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_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_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).
quadrant-n Identifier of the quadrant (0: AAI, 1: ELI: 2, SAI: quadrant-n Identifier of the quadrant (0: AAI, 1: ELI, 2:
3, 4: reserved). Each quadrant MUST only appear once Reserved, 3: SAI). Each quadrant MUST only appear
at most in the option. If an option includes more once at most in the option.
than one occurence of the same quadrant, only the
first occurence is processed and the rest MUST be
ignored by the server.
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. If a same means a more preferred quadrant.
preference value is used for more than one quadrant,
it is left to the server implementation which
quadrant should be preferred (if the server can
assign addresses from all of some of the quadrants
with the same assigned preference).
If the client or relay agent provide the OPTION_QUAD, the server uses A quadrant value MUST only appear once at most in the option. If an
the quadrant-n/pref-n values to order the selection of the quadrants. option includes more than one occurence of the same quadrant value,
If the server can provide an assignment from one the specified only the first occurence is processed and the rest MUST be ignored by
quadrants, it should proceed with the assignment. If the server the server.
cannot provide an assignment from one of the specified quadrant-n
fields, it MUST NOT assign any addresses and return a status of If a same preference value is used for more than one quadrant, it is
NoQuadAvail (IANA-2) in the IA_LL Option. left to the server implementation which quadrant should be preferred
(if the server can assign addresses from all of some of the quadrants
with the same assigned preference).
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
quadrants. If the server can provide an assignment from one of the
specified quadrants, it should proceed with the assignment. If the
server cannot provide an assignment from one of the specified
quadrant-n fields, it MUST NOT assign any addresses and return a
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 Client and relay agent MUST NOT place the same quadrant value into
the option more than once; however servers should be capable of the option more than once; however servers should be capable of
dealing with this by using the more preferred instance (as it dealing with this by using the more preferred instance (as it
requires no special handling). requires no special handling).
If the same preference value is used for more than one quadrant, the
behavior as to which is more preferred is random.
6. IANA Considerations 6. IANA Considerations
IANA is kindly requested to assign new values for option QUAD (IANA- IANA is requested to assign the QUAD (IANA-1) option code from the
1) and NoQuadAvail error code (IANA-2) and to update the registry DHCPv6 "Option Codes" registry maintained at
maintained at http://www.iana.org/assignments/dhcpv6-parameters. http://www.iana.org/assignments/dhcpv6-parameters and use the
following data when adding the option to the registry:
Value: IANA-1
Description: OPTION_SLAP_QUAD
Client ORO: No
Singleton Option: No
Reference: this document
IANA is requested to assign the NoQuadAvail (IANA-2) code from the
DHCPv6 "Status Codes" registry maintained
athttp://www.iana.org/assignments/dhcpv6-parameters and use the
following data when adding the option to the registry:
Value: IANA-2
Description: NoQuadAvail
Reference: this document
7. Security Considerations 7. Security Considerations
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 for his comments on this document. We also want to thank Ian Farrer and
very detailed and helpful review. 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 5G-CORAL project (Grant 761586). the framework of the H2020 5Growth (Grant 856709) and 5G-DIVE
projects (Grant 859881).
9. References 9. References
9.1. Normative References 9.1. Normative References
[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>.
skipping to change at page 15, line 43 skipping to change at page 16, line 34
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-02 (work in progress), January 2020. dhc-mac-assign-03 (work in progress), January 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. 26 change blocks. 
69 lines changed or deleted 101 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/