Internet DRAFT - draft-ietf-dhc-mac-assign
draft-ietf-dhc-mac-assign
Dynamic Host Configuration (DHC) B. Volz
Internet-Draft Cisco
Intended status: Standards Track T. Mrugalski
Expires: March 7, 2021 ISC
CJ. Bernardos
UC3M
September 3, 2020
Link-Layer Addresses Assignment Mechanism for DHCPv6
draft-ietf-dhc-mac-assign-09
Abstract
In certain environments, e.g., large scale virtualization
deployments, new devices are created in an automated manner. Such
devices may have their link-layer addresses assigned in an automated
fashion. With sufficient scale, the likelihood of a collision using
random assignment without duplication detection is not acceptable.
Therefore an allocation mechanism is required. This draft proposes
an extension to DHCPv6 that allows a scalable approach to link-layer
address assignments where preassigned link-layer address assignments
(such as by a manufacturer) are not possible or unnecessary.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 7, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Volz, et al. Expires March 7, 2021 [Page 1]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Deployment scenarios and mechanism overview . . . . . . . . . 4
4.1. Proxy client mode scenario . . . . . . . . . . . . . . . 4
4.2. Direct client mode scenario . . . . . . . . . . . . . . . 5
4.3. Mechanism Overview . . . . . . . . . . . . . . . . . . . 5
5. Design Assumptions . . . . . . . . . . . . . . . . . . . . . 6
6. Information Encoding . . . . . . . . . . . . . . . . . . . . 7
7. Requesting Addresses . . . . . . . . . . . . . . . . . . . . 7
8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 9
9. Releasing Addresses . . . . . . . . . . . . . . . . . . . . . 9
10. Option Definitions . . . . . . . . . . . . . . . . . . . . . 9
10.1. Identity Association for Link-Layer Addresses Option . . 10
10.2. Link-Layer Addresses Option . . . . . . . . . . . . . . 12
11. Selecting Link-Layer Addresses for Assignment to an IA_LL . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
16.1. Normative References . . . . . . . . . . . . . . . . . . 16
16.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
There are several deployment types that deal with a large number of
devices that need to be initialized. One of them is a scenario where
virtual machines (VMs) are created on a massive scale. Typically the
new VM instances are assigned a link-layer address, but random
assignment does not scale well due to the risk of a collision (see
Appendix A.1 of [RFC4429]). Another use case is IoT (Internet of
Things) devices (see [RFC7228]). The huge number of such devices
could strain the IEEE's available OUI (Organizationally Unique
Identifier) global address space. While there is typically no need
to provide global link-layer address uniqueness for such devices, a
Volz, et al. Expires March 7, 2021 [Page 2]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
link-layer assignment mechanism allows for conflicts to be avoided
inside an administrative domain. For those reasons, it is desired to
have some form of mechanism that would be able to assign locally
unique MAC (media access control) addresses.
This document proposes a new mechanism that extends DHCPv6 operation
to handle link-layer address assignments.
Since DHCPv6 ([RFC8415]) is a protocol that can allocate various
types of resources (non-temporary addresses, temporary addresses,
prefixes, as well as many options) and has the necessary
infrastructure to maintain such allocations (numerous server and
client implementations, large deployed relay infrastructure, and
supportive solutions such as leasequery and failover), it is a good
candidate to address the desired functionality.
While this document presents a design that should be usable for any
link-layer address type, some of the details are specific to IEEE 802
48-bit MAC addresses [IEEEStd802]. Future documents may provide
specifics for other link-layer address types.
IEEE 802 originally set aside half of the 48-bit MAC address space
for local use (where the U/L bit is set to 1). In 2017, IEEE
published an amendment [IEEEStd802c] that divides this space into
quadrants with differentied address rules. More details are in
Appendix A.
IEEE is also developing protocols and procedures for assignment of
locally unique addresses (IEEE 802.1CQ). This work may serve as an
alternative protocol for assignment. For additional background, see
[IEEE-P802.1CQ-Project].
2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
The DHCP terminology relevant to this specification from [RFC8415]
applies here. The following definitions either modify those
definitions as to how they are used in this document or define new
terminology used herein.
Volz, et al. Expires March 7, 2021 [Page 3]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
address Unless specified otherwise, an address means a link-
layer (or MAC) address, as specified in [IEEEStd802].
The address is typically six octets long, but some
network architectures may use different lengths.
address block A number of consecutive link-layer addresses. An
address block is expressed as a first address plus a
number that designates the number of additional (extra)
addresses. A single address can be represented by the
address itself and zero extra addresses.
client A node that is interested in obtaining link-layer
addresses. It implements the basic DHCP mechanisms
needed by a DHCP client as described in [RFC8415] and
supports the new options (IA_LL and LLADDR, see below)
specified in this document. The client may or may not
support IPv6 address assignment and prefix delegation
as specified in [RFC8415].
IA_LL Identity Association for Link-Layer Address: an
identity association (IA) used to request or assign
link-layer addresses. See Section 10.1 for details on
the IA_LL option.
LLADDR Link-layer address option that is used to request or
assign a block of link-layer addresses. See
Section 10.2 for details on the LLADDR option.
server A node that manages link-layer address allocation and
is able to respond to client queries. It implements
basic DHCP server functionality as described in
[RFC8415] and supports the new options (IA_LL and
LLADDR) specified in this document. The server may or
may not support IPv6 address assignment and prefix
delegation as specified in [RFC8415].
4. Deployment scenarios and mechanism overview
This mechanism is designed to be generic and usable in many
deployments, but there are two scenarios it attempts to address in
particular: (i) proxy client mode, and (ii) direct client mode.
4.1. Proxy client mode scenario
This mode is used when an entity acts as a DHCP client and requests
available DHCP servers to assign one or more addresses (an address
block), to be then assigned for use by the final end-devices. Large-
scale virtualization is one application scenario for proxy client
Volz, et al. Expires March 7, 2021 [Page 4]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
mode. In such environments this entity is often called a hypervisor
and is frequently required to spawn new VMs. The hypervisor needs to
assign new addresses to those machines. The hypervisor does not use
those addresses for itself, but rather uses them to create new VMs
with appropriate addresses. It is worth pointing out the cumulative
nature of this scenario. Over time, the hypervisor is likely to
increase its address usage. Some obsolete VMs will be deleted and
their addresses are potentially eligible for reuse for new VMs.
4.2. Direct client mode scenario
This mode can be used when an entity acts as a DHCP client and
requests available DHCP servers to assign one or more addresses (an
address block) for its use. This usage scenario is related to IoT,
as described earlier (see Section 1). Upon first boot, for each
interface the device uses a temporary address, as described in
[IEEEStd802.11] or to be described in IEEE 802.1CQ
[IEEE-P802.1CQ-Project], to send initial DHCP packets to available
DHCP servers wherein the device requests a single address for that
network interface. Once the server assigns an address, the device
abandons its temporary address and uses the assigned (leased)
address.
Note that a client that operates as above that does not have a
globally unique link-layer address on any of its interfaces MUST NOT
use a link-layer based DUID (DHCP Unique Identifier). For more
details, refer to Section 11 of [RFC8415].
Also, a client that operates as above may run into issues if the
switch it is connected to prohibits or restricts link-layer address
changes. This may limit where this capability can be used, or may
require the administrator to adjust the configuration of the
switch(es) to allow a change in address.
4.3. Mechanism Overview
In all scenarios the protocol operates in fundamentally the same way.
The device requesting an address, acting as a DHCP client, will send
a Solicit message with a IA_LL option to all available DHCP servers.
That IA_LL option MUST include a LLADDR option specifying the link-
layer-type and link-layer-len and may include a specific address or
address block as a hint for the server. Each available server
responds with either a Reply message with committed address(es) (if
Rapid Commit was requested and honored) or an Advertise message with
offered address(es). The client selects a server's response as
governed by [RFC8415]. If necessary, the client sends a Request
message and the target server will then assign the address(es) and
Volz, et al. Expires March 7, 2021 [Page 5]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
send a Reply message. Once a Reply is received, the client can start
using those address(es).
Normal DHCP mechanisms are in use. The client is expected to
periodically renew the addresses as governed by T1 and T2 timers and
stop using the address once the valid lifetime expires. Renewals can
be administratively disabled by the server sending "infinity" as the
T1 and T2 values (see Section 7.7 of [RFC8415]). An administrator
may make the address assignment permanent by specifying use of the
"infinity" valid lifetime, as defined in Section 7.7 of [RFC8415].
The client can release addresses when they are no longer needed by
sending a Release message (see Section 18.2.7 of [RFC8415]).
Figure 9 in [RFC8415] shows a timeline diagram of the messages
exchanged between a client and two servers for the typical lifecycle
of one or more leases.
Confirm and Information-Request messages are not used in link-layer
address assignment. Decline should technically never be needed, but
see Section 11 for one situation where this message is needed.
Clients implementing this mechanism SHOULD use the Rapid Commit
option as specified in Section 5.1 and 18.2.1 of [RFC8415] to obtain
addresses with a 2-message exchange when possible.
Devices supporting this proposal MAY support the reconfigure
mechanism, as defined in Section 18.2.11 of [RFC8415]. If supported
by both server and client, the reconfigure mechanism allows the
administrator to immediately notify clients that the configuration
has changed and triggers retrieval of relevant changes immediately,
rather than after the T1 timer elapses. Since this mechanism
requires implementation of Reconfigure Key Authentication Protocol
(See Section 20.4 of [RFC8415]), small-footprint devices may choose
to not support it.
5. Design Assumptions
One of the essential aspects of this mechanism is its cumulative
nature, especially in the hypervisor scenario. The server-client
relationship does not look like other DHCP transactions in the
hypervisor scenario. In a typical environment, there would be one
server and a rather small number of hypervisors, possibly even only
one. However, over time the number of addresses requested by the
hypervisor(s) will increase as more VMs are spawned.
Another aspect crucial for efficient design is the observation that a
single client acting as hypervisor will likely use thousands of
Volz, et al. Expires March 7, 2021 [Page 6]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
addresses. An approach similar to what is used for IPv6 address or
prefix assignment (IA container with all assigned addresses listed,
one option for each address) would not work well. Therefore the
mechanism should operate on address blocks, rather than single
values. A single address can be treated as an address block with
just one address.
The DHCP mechanisms are reused to large degree, including message and
option formats, transmission mechanisms, relay infrastructure and
others. However, a device wishing to support only link-layer address
assignment is not required to support full DHCP. In other words, the
device may support only assignment of link-layer addresses, but not
IPv6 addresses or prefixes.
6. Information Encoding
A client MUST send a LLADDR option encapsulated in an IA_LL option to
specify the link-layer-type and link-layer-len values. For link-
layer-type 1 (Ethernet) and 6 (IEEE 802 Networks), a client sets the
link-layer-address field to:
1. All zeroes if the client has no hint as to the starting address
of the unicast address block. This address has the IEEE 802
individual/group bit set to 0 (individual).
2. Any other value to request a specific block of address starting
with the specified address
Encoding information for other link-layer-types may be added in the
future by publishing an RFC that specifies those values.
A client sets the extra-addresses field to either 0 for a single
address or the size of the requested address block minus 1.
A client MUST set the valid-lifetime field to 0 (this field MUST be
ignored by the server).
7. Requesting Addresses
The addresses are assigned in blocks. The smallest block is a single
address. To request an assignment, the client sends a Solicit
message with an IA_LL option in the message. The IA_LL option MUST
contain a LLADDR option as specified in Section 6.
The server, upon receiving an IA_LL option, inspects its content and
may offer an address or addresses for each LLADDR option according to
its policy. The server MAY take into consideration the address block
requested by the client in the LLADDR option. However, the server
Volz, et al. Expires March 7, 2021 [Page 7]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
MAY choose to ignore some or all parameters of the requested address
block. In particular, the server may send a different starting
address than requested, or a smaller number of addresses than
requested. The server sends back an Advertise message with an IA_LL
option containing an LLADDR option that specifies the addresses being
offered. If the server is unable to provide any addresses it MUST
return the IA_LL option containing a Status Code option (see
Section 21.13 of [RFC8415]) with status set to NoAddrsAvail.
Note: Servers that do not support the IA_LL option will ignore the
option and not return it in Advertise (and Reply) messages. Clients
that send IA_LL options MUST treat this as if the server returned the
NoAddrsAvail status for these IA_LL option(s).
The client waits for available servers to send Advertise responses
and picks one server as defined in Section 18.2.9 of [RFC8415]. The
client then sends a Request message that includes the IA_LL container
option with the LLADDR option copied from the Advertise message sent
by the chosen server.
The client MUST process the address block(s) returned in the
Advertise, rather than what it included in the Solicit, and may
consider the offered address block(s) in selecting the Advertise to
accept. The server may offer a smaller number of addresses or
different addresses from those requested. A client MUST NOT use
resources returned in an Advertise message except to select a server
and in sending the Request to that server; resources are only useable
by a client when returned in a Reply message.
Upon reception of a Request message with IA_LL container option, the
server assigns the requested addresses. The server allocates a block
of addresses according to its configured policy. The server MAY
assign a different block or smaller block size than requested in the
Request message. The server then generates and sends a Reply message
back to the client.
Upon receiving a Reply message, the client parses the IA_LL container
option and may start using all provided addresses. It MUST restart
its T1 and T2 timers using the values specified in the IA_LL option.
The client MUST use the address block(s) returned in the Reply
message, which may be smaller block(s) or with different address(es)
than requested.
A client that has included a Rapid Commit option in the Solicit may
receive a Reply in response to the Solicit and skip the Advertise and
Request steps above (see Section 18.2.1 of [RFC8415]).
Volz, et al. Expires March 7, 2021 [Page 8]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
A client that changes its link-layer address on an interface SHOULD
follow the recommendations in Section 7.2.6 of [RFC4861] to inform
its neighbors of the new link-layer address quickly.
8. Renewing Addresses
Address renewals follow the normal DHCP renewals processing described
in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, the
client starts sending Renew messages with the IA_LL option containing
a LLADDR option for the address block being renewed. The server
responds with a Reply message that contains the renewed address
block. The server MUST NOT shrink or expand the address block. Once
a block is assigned and has a non-zero valid lifetime, its size,
starting address, and ending address MUST NOT change.
If the requesting client needs additional addresses -- e.g., in the
hypervisor scenario because addresses need to be assigned to new VMs
-- it MUST send an IA_LL option with a different IAID to create
another "container" for more addresses.
If the client is unable to Renew before the T2 timer elapses, it
starts sending Rebind messages as described in Section 18.2.5 of
[RFC8415].
9. Releasing Addresses
The client may decide to release a leased address block. A client
MUST release the whole block in its entirety. A client releases an
address block by sending a Release message that includes an IA_LL
option containing the LLADDR option for the address block to release.
The Release transmission mechanism is described in Section 18.2.7 of
[RFC8415].
Note: If the client is releasing the link-layer address it is using,
it MUST stop using this address before sending the Release message
(as per [RFC8415]). In order to send the Release message, the client
MUST use another address (such as the one originally used to initiate
DHCPv6 to provide an allocated link-layer address).
10. Option Definitions
This mechanism uses an approach similar to the existing mechanisms in
DHCP. There is one container option (the IA_LL option) that contains
the actual address or addresses, represented by an LLADDR option.
Each LLADDR option represents an address block, which is expressed as
a first address with a number that specifies how many additional
addresses are included.
Volz, et al. Expires March 7, 2021 [Page 9]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
10.1. Identity Association for Link-Layer Addresses Option
The Identity Association for Link-Layer Addresses option (IA_LL
option) is used to carry an IA_LL, the parameters associated with the
IA_LL, and the address blocks associated with the IA_LL.
The format of the IA_LL option is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_LL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IA_LL-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IA_LL Option Format
option-code OPTION_IA_LL (tbd1).
option-len 12 + length of IA_LL-options field.
IAID The unique identifier for this IA_LL; the IAID must
be unique among the identifiers for all of this
client's IA_LLs. The number space for IA_LL IAIDs is
separate from the number space for other IA option
types (i.e., IA_NA, IA_TA, and IA_PD). A 4-octet
field containing an unsigned integer.
T1 The time interval after which the client should
contact the server from which the addresses in the
IA_LL were obtained to extend the valid lifetime of
the addresses assigned to the IA_LL; T1 is a time
duration relative to the current time expressed in
units of seconds. A 4-octet field containing an
unsigned integer.
T2 The time interval after which the client should
contact any available server to extend the valid
lifetime of the addresses assigned to the IA_LL; T2
Volz, et al. Expires March 7, 2021 [Page 10]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
is a time duration relative to the current time
expressed in units of seconds. A 4-octet field
containing an unsigned integer.
IA_LL-options Options associated with this IA_LL. A variable
length field (12 octets less than the value in the
option-len field).
An IA_LL option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_LL options (though
each must have a unique IAID).
The status of any operations involving this IA_LL is indicated in a
Status Code option (see Section 21.13 of [RFC8415]) in the IA_LL-
options field.
Note that an IA_LL has no explicit "lifetime" or "lease length" of
its own. When the valid lifetimes of all of the addresses in an
IA_LL have expired, the IA_LL can be considered as having expired.
T1 and T2 are included to give servers explicit control over when a
client recontacts the server about a specific IA_LL.
In a message sent by a client to a server, the T1 and T2 fields MUST
be set to 0. The server MUST ignore any values in these fields in
messages received from a client.
In a message sent by a server to a client, the client MUST use the
values in the T1 and T2 fields for the T1 and T2 times, unless those
values in those fields are 0. The values in the T1 and T2 fields are
the number of seconds until T1 and T2.
As per Section 7.7 of [RFC8415]), the value 0xffffffff is taken to
mean "infinity" and should be used carefully.
The server selects the T1 and T2 times to allow the client to extend
the lifetimes of any address block in the IA_LL before the lifetimes
expire, even if the server is unavailable for some short period of
time. Recommended values for T1 and T2 are .5 and .8 times the
shortest valid lifetime of the address blocks in the IA that the
server is willing to extend, respectively. If the "shortest" valid
lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values
are also 0xffffffff. If the time at which the addresses in an IA_LL
are to be renewed is to be left to the discretion of the client, the
server sets T1 and T2 to 0. The client MUST follow the rules defined
in Section 14.2 in [RFC8415].
If a client receives an IA_LL with T1 greater than T2, and both T1
and T2 are greater than 0, the client discards the IA_LL option and
Volz, et al. Expires March 7, 2021 [Page 11]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
processes the remainder of the message as though the server had not
included the invalid IA_LL option.
The IA_LL-options field typically contains one or more LLADDR options
(see Section 10.2). If a client does not include a LLADDR option in
a Solicit or Request message, the server MUST treat this as a request
for a single address and that the client has no hint as to the
address it would like.
10.2. Link-Layer Addresses Option
The Link-Layer Addresses option is used to specify an address block
associated with an IA_LL. The option must be encapsulated in the
IA_LL-options field of an IA_LL option. The LLaddr-options fields
encapsulates those options that are specific to this address block.
The format of the Link-Layer Addresses option is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LLADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-layer-type | link-layer-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer-address .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extra-addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. LLaddr-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LLADDR Option Format
option-code OPTION_LLADDR (tbd2).
option-len 12 + link-layer-len field value + length of LLaddr-
options field. Assuming a link-layer-address length
of 6 and no extra options, the option-len would be
18.
Volz, et al. Expires March 7, 2021 [Page 12]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
link-layer-type The link-layer type MUST be a valid hardware type
assigned by the IANA, as described in [RFC5494] and
in the "Hardware Types" table at
https://www.iana.org/assignments/arp-parameters. A
2-octet field containing an unsigned integer.
link-layer-len Specifies the length, in octets, of the link-layer-
address field (typically 6, for a link-layer-type of
1 (Ethernet) and 6 (IEEE 802 Networks)). This is to
accommodate link-layers that may have variable-length
addresses. A 2-octet field containing an unsigned
integer.
link-layer-address Specifies the address of the first link-layer
address that is being requested or assigned depending
on the message. A client MAY send a special value to
request any address. For a link-layer type of 1 and
6, see Section 6 for details on this field. A link-
layer-len length octet field containing an address.
extra-addresses Specifies the number of additional addresses that
follow the address specified in link-layer-address.
For a single address, 0 is used. For example: link-
layer-address: 02:04:06:08:0a and extra-addresses 3
designates a block of 4 addresses, starting from
02:04:06:08:0a and ending with 02:04:06:08:0d
(inclusive). A 4-octet field containing an unsigned
integer.
valid-lifetime The valid lifetime for the address(es) in the option,
expressed in units of seconds. A 4-octet field
containing an unsigned integer.
LLaddr-options Any encapsulated options that are specific to this
particular address block. Currently there are no
such options defined, but there may be in the future.
In a message sent by a client to a server, the valid lifetime field
MUST be set to 0. The server MUST ignore any received value.
In a message sent by a server to a client, the client MUST use the
value in the valid lifetime field for the valid lifetime for the
address block. The value in the valid lifetime field is the number
of seconds remaining in the lifetime.
As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is
taken to mean "infinity" and should be used carefully.
Volz, et al. Expires March 7, 2021 [Page 13]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
More than one LLADDR option can appear in an IA_LL option.
11. Selecting Link-Layer Addresses for Assignment to an IA_LL
A server selects link-layer addresses to be assigned to an IA_LL
according to the assignment policies determined by the server
administrator and the requirements of that address space.
Link-layer addresses are typically specific to a link and the server
SHOULD follow the steps in Section 13.1 of [RFC8415] to determine the
client's link.
For IEEE 802 MAC addresses (see [IEEEStd802] as amended by
[IEEEStd802c]):
1. Server administrators SHOULD follow the IEEE 802 Specifications
with regards to the unicast address pools made available for
assignment (see Appendix A and [IEEEStd802c]) -- only address
space reserved for local use or with the authorization of the
assignee may be used.
2. Servers MUST NOT allow administrators to configure address pools
that would cross the 2^42 bit boundary (for 48-bit MAC addresses)
to avoid issues with changes in the first octet of the address
and the special bits therein (see Appendix A). Clients MUST
reject assignments where the assigned block would cross this
boundary (they MUST decline the allocation - see Section 18.2.8
of [RFC8415]).
3. A server MAY use options supplied by a relay agent or client to
select the quadrant (see Appendix A) from which addresses are to
be assigned. This MAY include options, such as those specified
in [I-D.ietf-dhc-slap-quadrant].
12. IANA Considerations
IANA is requested to assign the OPTION_IA_LL (tbd1) option code from
the DHCPv6 "Option Codes" registry maintained at
http://www.iana.org/assignments/dhcpv6-parameters and use the
following data when adding the option to the registry:
Value: tbd1
Description: OPTION_IA_LL
Client ORO: No
Singleton Option: No
Reference: this document
Volz, et al. Expires March 7, 2021 [Page 14]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
IANA is requested to assign the OPTION_LLADDR (tbd2) option code from
the DHCPv6 "Option Codes" registry maintained at
http://www.iana.org/assignments/dhcpv6-parameters and use the
following data when adding the option to the registry:
Value: tbd2
Description: OPTION_LLADDR
Client ORO: No
Singleton Option: No
Reference: this document
13. Security Considerations
See Section 22 of [RFC8415] and Section 23 of [RFC7227] for the DHCP
security considerations. See [RFC8200] for the IPv6 security
considerations.
As discussed in Section 22 of [RFC8415], "DHCP lacks end-to-end
encryption between clients and servers; thus, hijacking, tampering,
and eavesdropping attacks are all possible as a result." In some
network environments, it is possible to secure them as discussed
later in that Section 22.
There is a possibility of the same link-layer address being used by
more than one device if not all parties on a link use this mechanism
to obtain an address from the space assigned to the DHCP server.
Note that this issue would exist on these networks even if DHCP were
not used to obtain the address.
Server implementations SHOULD consider configuration options to limit
the maximum number of addresses to allocate (both in a single request
and in total) to a client. However, note that this does not prevent
a bad client actor from pretending to be many different clients and
consuming all available addresses.
14. Privacy Considerations
See Section 23 of [RFC8415] for the DHCP privacy considerations.
For a client requesting a link-layer address directly from a server,
as the address assigned to a client will likely be used by the client
to communicate on the link, the address will be exposed to those able
to listen in on this communication. For those peers on the link that
are able to listen in on the DHCP exchange, they would also be able
to correlate the client's identity (based on the DUID used) with the
assigned address. Additional mechanisms, such as the ones described
Volz, et al. Expires March 7, 2021 [Page 15]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
in [RFC7844] can also be used to improve anonymity by minimizing what
is exposed.
As discussed in Section 23 of [RFC8415], DHCP servers and hypervisors
may need to consider the implications of assigning addresses
sequentially. Though in general, this is only of link-local concern
unlike for IPv6 address assignment and prefix delegation as these may
be used for communication over the Internet.
15. Acknowledgements
Thanks to the DHC Working Group participants that reviewed this
document, provided comments, and support. With special thanks to Ian
Farrer for his thorough reviews and shepherding of this document
through the IETF process. Thanks also to area reviewers Samita
Chakrabarti, Roni Even and Tianran Zhou, and IESG members Martin
Duke, Benjamin Kaduk, Murray Kucherawy, Warren Kumari, Barry Leiba,
Alvaro Retana, Eric Vyncke, and Robert Wilton for their suggestions.
And to Roger Marks, Bob Grow, and Antonio de la Oliva for comments
related to IEEE work and references.
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
Volz, et al. Expires March 7, 2021 [Page 16]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
16.2. Informative References
[I-D.ietf-dhc-slap-quadrant]
Bernardos, C. and A. Mourad, "SLAP quadrant selection
option for DHCPv6", draft-ietf-dhc-slap-quadrant-10 (work
in progress), August 2020.
[IEEE-P802.1CQ-Project]
"P802.1CQ - Standard for Local and Metropolitan Area
Networks: Multicast and Local Address Assignment",
<https://standards.ieee.org/project/802_1CQ.html>.
[IEEEStd802]
"IEEE Standard for Local and Metropolitan Area Networks:
Overview and Architecture, IEEE Std 802".
[IEEEStd802.11]
"IEEE Standard for Information technology -
Telecommunications and information exchange between
systems Local and metropolitan area networks - Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications, IEEE Std
802.11".
[IEEEStd802c]
"IEEE Standard for Local and Metropolitan Area Networks:
Overview and Architecture, Amendment 2: Local Medium
Access Control (MAC) Address Usage, IEEE Std 802c-2017".
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>.
[RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines
for the Address Resolution Protocol (ARP)", RFC 5494,
DOI 10.17487/RFC5494, April 2009,
<https://www.rfc-editor.org/info/rfc5494>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<https://www.rfc-editor.org/info/rfc7227>.
Volz, et al. Expires March 7, 2021 [Page 17]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/info/rfc7844>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Appendix A. IEEE 802c Summary
This appendix provides a brief summary of IEEE 802c [IEEEStd802c].
The original IEEE 802 specifications assigned half of the 48-bit MAC
address space to local use -- these addresses have the U/L bit set to
1 and are locally administered with no imposed structure.
In 2017, the IEEE issued the IEEE Std 802c specification which
defines a new optional "Structured Local Address Plan (SLAP) that
specifies different assignment approaches in four specified regions
of the local MAC address space." Under this plan, there are 4 SLAP
quadrants that use different assignment policies.
The first octet of the MAC address Z and Y bits define the quadrant
for locally assigned addresses (X-bit is 1). In IEEE representation,
these bits are as follows:
LSB MSB
M X Y Z - - - -
| | | |
| | | +------------ SLAP Z-bit
| | +--------------- SLAP Y-bit
| +------------------ X-bit (U/L) = 1 for locally assigned
+--------------------- M-bit (I/G) (unicast/group)
Figure 3: SLAP Bits
The SLAP quadrants are:
Volz, et al. Expires March 7, 2021 [Page 18]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
+----------+-------+-------+-----------------------+----------------+
| Quadrant | Y-bit | Z-bit | Local Identifier Type | Local |
| | | | | Identifier |
+----------+-------+-------+-----------------------+----------------+
| 01 | 0 | 1 | Extended Local | ELI |
| 11 | 1 | 1 | Standard Assigned | SAI |
| 00 | 0 | 0 | Administratively | AAI |
| | | | Assigned | |
| 10 | 1 | 0 | Reserved | Reserved |
+----------+-------+-------+-----------------------+----------------+
SLAP Quadrants
Extended Local Identifier (ELI) derived MAC addresses are based on an
assigned Company ID (CID), which is 24-bits (including the M, X, Y,
and Z bits) for 48-bit MAC addresses. This leaves 24-bits for the
locally assigned address for each CID for unicast (M-bit = 0) and
also for multicast (M-bit = 1). The CID is assigned by the IEEE RA.
Standard Assigned Identifier (SAI) derived MAC addresses are assigned
by a protocol specified in an IEEE 802 standard. For 48-bit MAC
addresses, 44 bits are available. Multiple protocols for assigning
SAIs may be specified in IEEE standards. Coexistence of multiple
protocols may be supported by limiting the subspace available for
assignment by each protocol.
Administratively Assigned Identifier (AAI) derived MAC addresses are
assigned locally. Administrators manage the space as needed. Note
that multicast IPv6 packets ([RFC2464]) use a destination address
starting in 33-33, so AAI addresses in that range should not be
assigned. For 48-bit MAC addresses, 44 bits are available.
The last quadrant is reserved for future use. While this quadrant
may also be used similar to AAI space, administrators should be aware
that future specifications may define alternate uses that could be
incompatible.
Authors' Addresses
Bernie Volz
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719
USA
Email: volz@cisco.com
Volz, et al. Expires March 7, 2021 [Page 19]
Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020
Tomek Mrugalski
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Email: tomasz.mrugalski@gmail.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Volz, et al. Expires March 7, 2021 [Page 20]
