Link-Layer Addresses Assignment Mechanism for DHCPv6Cisco Systems, Inc.1414 Massachusetts AveBoxborough, MA 01719USAvolz@cisco.comInternet Systems Consortium,
Inc.950 Charter StreetRedwood CityCA94063USAtomasz.mrugalski@gmail.comUniversidad Carlos III de
MadridAv. Universidad, 30Leganes, Madrid28911Spain+34 91624 6236cjbc@it.uc3m.eshttp://www.it.uc3m.es/cjbc/
Internet
Dynamic Host Configuration (DHC)DHCPv6DHCPLink-layerassignmentIn certain environments, e.g. large scale virtualization deployments,
new devices are created in an automated manner. Such devices typically have
their link-layer (MAC) addresses randomized. With sufficient scale, the
likelihood of collision 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.There are several new 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 random link-layer (MAC) address, but that does
not scale well due to the birthday paradox. Another use case is IoT devices.
The huge number of such devices would likely exhaust a vendor's OUI
(Organizationally Unique Identifier) global address space, and while there
is typically no need to provide global uniqueness for such devices, a
link-layer assignment mechanisms allows for conflicts to be avoided inside
an administrative domain. For those reasons, it is desired to have some form
of authority that would be able to assign locally unique MAC addresses.This document proposes a new mechanism that extends DHCPv6 operation to
handle link-layer address assignments.Since DHCPv6 () is a protocol
that can allocate various types of resources (non-temporary addresses,
temporary addresses, prefixes, but also many options) and has necessary
infrastructure (numerous server and client implementations, large deployed
relay infrastructure, supportive solutions, like leasequery and failover)
to maintain such assignment, 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 Ethernet /
IEEE 802 48-bit MAC addresses. Future documents may provide specifics for
other link-layer address types.The IEEE 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, the IEEE specified an
optional specification (IEEE 802c) that divides this space into quadrants
(Standards Assigned Identifier, Extended Local Identifier,
Administratively Assigned Identifier, and a Reserved quadrant) - more
details are in .The IEEE is also working to specify protocols and procedures for
assignment of locally unique addresses (IEEE 802.1cq). This work may
serve as one such protocol for assignment. For additional background, see
.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
when, and only when,
they appear in all capitals, as shown here.The DHCP terminology relevant to this specification from
applies here.A device that is interested in obtaining link-layer
addresses. It implements the basic DHCP mechanisms needed by a DHCP
client as described in and
supports the new options (IA_LL and LLADDR) specified in this
document. The client may or may not support IPv6 address assignment
and prefix delegation as specified in .Software that manages link-layer address allocation
and is able to respond to client queries. It implements basic DHCP
server functionality as described in 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 .Unless specified otherwise, an address means a
link-layer (or MAC) address, as defined in IEEE 802. The address is
typically 6 octets long, but some network architectures may use
different lengths.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.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.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 to the final end-devices. One relevant example of
scenario of application of this mode is large scale virtualization. In such
environments the governing 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 addresses usage. Some obsolete VMs
will be deleted and their addresses will be eligible for reuse for new VMs.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)
for its own use. This usage scenario is related to IoT (Internet of Things). With
the emergence of IoT, a new class of cheap, sometimes short lived and
disposable devices, has emerged. Examples may include various sensors
(e.g. medical) and actuators or controllable LED lights. Upon first boot,
the device uses a temporary address, as described in , to send initial DHCP packets to available
DHCP servers. Then, such devices would typically request a single address for
each available network interface, which typically means one address per
device. Once the server assigns a 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), i.e., DUID-LLT or DUID-LL.
For more details, refer to Section 11 of .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 specify a specific address or address
block as a hint for the server. Each available server responds with an Advertise
message with offered address or addresses. The client then picks the best
server, as governed by , and will
send a Request message. The target server will then assign the
addresses and send a Reply message. Upon reception, the client can start
using those addresses.Normal DHCP mechanisms are in use. The client is expected to
periodically renew the 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
).The client can release addresses when they are no longer
needed by sending a Release message (see Section 18.2.7
of )., taken from ,
shows a timeline diagram of the messages exchanged between a client and two servers
for the typical lifecycle of one or more leasesConfirm, Decline, and Information-Request
messages are not used in link-layer address assignment.Clients implementing this mechanism SHOULD use the Rapid Commit option
as specified in Section 5.1 and 18.2.1 of
.An administrator may make the address assignment permanent by specifying
use of infinite lifetimes, as defined in Section 7.7 of . An administrator may also disable
the need for the renewal mechanism by setting the T1 and T2 values to
infinity.Devices supporting this proposal MAY support the reconfigure mechanism,
as defined in Section 18.2.11 of .
If supported by both server and client, this 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 ), small
footprint devices may choose to not support it.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. This is
especially true 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 likely increase as new VMs are spawned.Another aspect crucial for efficient design is the observation that a
single client acting as hypervisor will likely use thousands of
addresses. Therefore 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.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 / IEEE 802 48-bit MAC addresses), a client sets
the link-layer-address field to:
00:00:00:00:00:00 (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).
Any other value to request a specific block of
address starting with the specified address
A client sets the extra-addresses field to
either 0 for a single address or to the size of the requested
address block minus 1.A client SHOULD set the valid-lifetime field to 0 (this field MUST be
ignored by the server).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 .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 MAY chose to
ignore some or all parameters of the requested address block. In
particular, the server may send a different starting address than
requested, or grant a smaller number of addresses than requested. The
server sends back an Advertise message 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 ) with status set to NoAddrsAvail.The client MUST be able to handle an Advertise message containing a
smaller number of addresses, or an address or addresses different than those
requested.The client waits for available servers to send Advertise responses and
picks one server as defined in Section 18.2.9 of . 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.Upon reception of a Request message with IA_LL container option, the
server assigns requested addresses. The server allocates block of addresses
according to its configured policy. The server MAY assign a different block
than requested in the Request message. It 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 be able to handle a Reply message containing a smaller
number of addresses, or an address or addresses different than those
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
).A client that changes its link-layer address on an interface SHOULD
follow the recommendations in Section 7.2.6 of
to inform its neighbors of the new link-layer address quickly.Address renewals follow the normal DHCP renewals processing
described in Section
18.2.4 of . 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 -- the
simpler approach is for the requesting device to keep the address blocks as
atomic once "leased". Therefore, if a client wants more addresses at a later
stage, it SHOULD 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 18.2.5 of
.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 the 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 .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 such option represents an address block, which is expressed
as a first address with a number that specifies how many
additional addresses are included.The Identity Association for Link-Layer Addresses option (IA_LL
option) is used to carry one or more IA_LL options, the parameters
associated with the IA_LL, and the address blocks associated with
the IA_LL.The format of the IA_LL option is:OPTION_IA_LL (tbd1).12 + length of IA_LL-options field.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.The time at 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.The time at which the client should contact
any available server to extend the valid lifetime
of the addresses assigned to the IA_LL; T2 is
a time duration relative to the current time
expressed in units of seconds. A 4-octet field
containing an unsigned integer.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
) 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
SHOULD 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 ),
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 .
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
processes the remainder of the message as though the server had not
included the invalid IA_LL option.The Link-Layer Addresses option is used to specify an address block
associated with a 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:OPTION_LLADDR (tbd2).12 + link-layer-len field
(typically 6) + length of LLaddr-options field. Assuming a typical
link-layer address of 6 is used and there are no extra
options, length should be equal to 18.The link-layer type MUST be a
valid hardware type assigned by the IANA, as described in
and in the "Hardware Types" table at
https://www.iana.org/assignments/arp-parameters.
A 2-octet field containing an unsigned integer.Specifies the length, in octets, of the
link-layer-address field (typically 6, for a link-layer-type
of 1 (Ethernet)). A 2-octet field containing an unsigned
integer.Specifies the
link-layer address that is being requested or renewed, or
a special value to request any address. For a link-layer
type of 1 (Ethernet / IEEE 802 48-bit MAC addresses), see
for details on these
values. In responses from a server, this
value specifies the first address allocated.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). In responses from a server,
this value specifies the number of additional addresses
allocated. A 4-octet field containing an unsigned integer.The valid lifetime for the
address(es) in the option, expressed in units of seconds.
A 4-octet field containing an unsigned integer.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 SHOULD 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 ,
the valid lifetime of 0xffffffff is taken to mean "infinity" and
should be used carefully.More than one LLADDR option can appear in an IA_LL option.A server selects link-layer addresses to be assigned to an IA_LL
according to the assignment policies determined by the server
administrator.Link-layer addresses are typically specific to a link and the
server SHOULD follow the steps in Section 13.1 of
to determine the client's link.For Ethernet / IEEE 802 MAC addresses, a server MAY use additional
options supplied by a relay agent or client to select the quadrant
(see ) from which addresses are to
be assigned. This MAY include new options, such as those specified
in .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: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:See for the DHCP
security considerations. See for the
IPv6 security considerations.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 a link-layer address from the space
assigned to the DHCP server. It is also possible that a bad actor
purposely uses a device's link-layer address.See 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
in can also be used.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.
Emerging IEEE 802 Work on MAC Addressing
Temporary MAC address for anonymity
IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture,
Amendment 2: Local Medium Access Control (MAC) Address Usage, IEEE Std 802c-2017
IEEE Computer SocietyThis appendix provides a brief summary of IEEE 802c from
.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 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:The SLAP quadrants are:QuadrantY-bitZ-bitLocal Identifier TypeLocal Identifier0101Extended LocalELI1111Standard AssignedSAI0000Administratively AssignedAAI1010ReservedReservedExtended 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 () use a destination address
starting in 33-33 and this falls within this space and therefore should
not be used to avoid conflict with IPv6 multicast addresses. For
48-bit MAC addresses, 44 bits are available.The last quadrant is reserved for future use. While this quadrant may
also be used for AAI space, administrators should be aware that future
specifications may define alternate uses that could be incompatible.