draft-ietf-dhc-mac-assign-05.txt   draft-ietf-dhc-mac-assign-06.txt 
Dynamic Host Configuration (DHC) B. Volz Dynamic Host Configuration (DHC) B. Volz
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track T. Mrugalski Intended status: Standards Track T. Mrugalski
Expires: September 17, 2020 ISC Expires: November 5, 2020 ISC
CJ. Bernardos CJ. Bernardos
UC3M UC3M
March 16, 2020 May 4, 2020
Link-Layer Addresses Assignment Mechanism for DHCPv6 Link-Layer Addresses Assignment Mechanism for DHCPv6
draft-ietf-dhc-mac-assign-05 draft-ietf-dhc-mac-assign-06
Abstract Abstract
In certain environments, e.g. large scale virtualization deployments, In certain environments, e.g. large scale virtualization deployments,
new devices are created in an automated manner. Such devices new devices are created in an automated manner. Such devices
typically have their link-layer (MAC) addresses randomized. With typically have their link-layer (MAC) addresses randomized. With
sufficient scale, the likelihood of collision is not acceptable. sufficient scale, the likelihood of collision is not acceptable.
Therefore an allocation mechanism is required. This draft proposes Therefore an allocation mechanism is required. This draft proposes
an extension to DHCPv6 that allows a scalable approach to link-layer an extension to DHCPv6 that allows a scalable approach to link-layer
address assignments. address assignments.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 17, 2020. This Internet-Draft will expire on November 5, 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 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Deployment scenarios and mechanism overview . . . . . . . . . 4 4. Deployment scenarios and mechanism overview . . . . . . . . . 4
4.1. Proxy client mode scenario . . . . . . . . . . . . . . . 4 4.1. Proxy client mode scenario . . . . . . . . . . . . . . . 4
4.2. Direct client mode scenario . . . . . . . . . . . . . . . 5 4.2. Direct client mode scenario . . . . . . . . . . . . . . . 5
4.3. Mechanism Overview . . . . . . . . . . . . . . . . . . . 5 4.3. Mechanism Overview . . . . . . . . . . . . . . . . . . . 5
5. Design Assumptions . . . . . . . . . . . . . . . . . . . . . 7 5. Design Assumptions . . . . . . . . . . . . . . . . . . . . . 7
6. Information Encoding . . . . . . . . . . . . . . . . . . . . 8 6. Information Encoding . . . . . . . . . . . . . . . . . . . . 8
7. Requesting Addresses . . . . . . . . . . . . . . . . . . . . 8 7. Requesting Addresses . . . . . . . . . . . . . . . . . . . . 8
8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 10 8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 9
9. Releasing Addresses . . . . . . . . . . . . . . . . . . . . . 10 9. Releasing Addresses . . . . . . . . . . . . . . . . . . . . . 10
10. Option Definitions . . . . . . . . . . . . . . . . . . . . . 10 10. Option Definitions . . . . . . . . . . . . . . . . . . . . . 10
10.1. Identity Association for Link-Layer Addresses Option . . 10 10.1. Identity Association for Link-Layer Addresses Option . . 10
10.2. Link-Layer Addresses Option . . . . . . . . . . . . . . 12 10.2. Link-Layer Addresses Option . . . . . . . . . . . . . . 12
11. Selecting Link-Layer Addresses for Assignment to an IA_LL . . 14 11. Selecting Link-Layer Addresses for Assignment to an IA_LL . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 3, line 4 skipping to change at page 3, line 4
of devices that need to be initialized. One of them is a scenario of devices that need to be initialized. One of them is a scenario
where virtual machines (VMs) are created on a massive scale. where virtual machines (VMs) are created on a massive scale.
Typically the new VM instances are assigned a random link-layer (MAC) Typically the new VM instances are assigned a random link-layer (MAC)
address, but that does not scale well due to the birthday paradox. address, but that does not scale well due to the birthday paradox.
Another use case is IoT devices. The huge number of such devices Another use case is IoT devices. The huge number of such devices
would likely exhaust a vendor's OUI (Organizationally Unique would likely exhaust a vendor's OUI (Organizationally Unique
Identifier) global address space, and while there is typically no Identifier) global address space, and while there is typically no
need to provide global uniqueness for such devices, a link-layer need to provide global uniqueness for such devices, a link-layer
assignment mechanisms allows for conflicts to be avoided inside an assignment mechanisms allows for conflicts to be avoided inside an
administrative domain. For those reasons, it is desired to have some administrative domain. For those reasons, it is desired to have some
form of local authority that would be able to assign locally unique form of authority that would be able to assign locally unique MAC
MAC addresses. addresses.
This document proposes a new mechanism that extends DHCPv6 operation This document proposes a new mechanism that extends DHCPv6 operation
to handle link-layer address assignments. to handle link-layer address assignments.
Since DHCPv6 ([RFC8415]) is a protocol that can allocate various Since DHCPv6 ([RFC8415]) is a protocol that can allocate various
types of resources (non-temporary addresses, temporary addresses, types of resources (non-temporary addresses, temporary addresses,
prefixes, but also many options) and has necessary infrastructure prefixes, but also many options) and has necessary infrastructure
(numerous server and client implementations, large deployed relay (numerous server and client implementations, large deployed relay
infrastructure, supportive solutions, like leasequery and failover) infrastructure, supportive solutions, like leasequery and failover)
to maintain such assignment, it is a good candidate to address the to maintain such assignment, it is a good candidate to address the
skipping to change at page 3, line 45 skipping to change at page 3, line 45
2. Requirements 2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
The DHCPv6 terminology relevant to this specification from the DHCPv6 The DHCP terminology relevant to this specification from [RFC8415]
Protocol [RFC8415] applies here. applies here.
client A device that is interested in obtaining link-layer client A device that is interested in obtaining link-layer
addresses. It implements the basic DHCPv6 mechanisms addresses. It implements the basic DHCP mechanisms
needed by a DHCPv6 client as described in [RFC8415] and needed by a DHCP client as described in [RFC8415] and
supports the new options (IA_LL and LLADDR) specified supports the new options (IA_LL and LLADDR) specified
in this document. The client may or may not support in this document. The client may or may not support
address assignment and prefix delegation as specified IPv6 address assignment and prefix delegation as
in [RFC8415]. specified in [RFC8415].
server Software that manages link-layer address allocation and server Software that manages link-layer address allocation and
is able to respond to client queries. It implements is able to respond to client queries. It implements
basic DHCPv6 server functionality as described in basic DHCP server functionality as described in
[RFC8415] and supports the new options (IA_LL and [RFC8415] and supports the new options (IA_LL and
LLADDR) specified in this document. The server may or LLADDR) specified in this document. The server may or
may not support address assignment and prefix may not support IPv6 address assignment and prefix
delegation as specified in [RFC8415]. delegation as specified in [RFC8415].
address Unless specified otherwise, an address means a link- address Unless specified otherwise, an address means a link-
layer (or MAC) address, as defined in IEEE802. The layer (or MAC) address, as defined in IEEE 802. The
address is typically 6 octets long, but some network address is typically 6 octets long, but some network
architectures may use different lengths. architectures may use different lengths.
address block A number of consecutive link-layer addresses. An address block A number of consecutive link-layer addresses. An
address block is expressed as a first address plus a address block is expressed as a first address plus a
number that designates the number of additional (extra) number that designates the number of additional (extra)
addresses. A single address can be represented by the addresses. A single address can be represented by the
address itself and zero extra addresses. address itself and zero extra addresses.
4. Deployment scenarios and mechanism overview 4. Deployment scenarios and mechanism overview
This mechanism is designed to be generic and usable in many This mechanism is designed to be generic and usable in many
deployments, but there are two scenarios it attempts to address in deployments, but there are two scenarios it attempts to address in
particular: (i) proxy client mode, and (ii) direct client mode. particular: (i) proxy client mode, and (ii) direct client mode.
4.1. Proxy client mode scenario 4.1. Proxy client mode scenario
This mode is used when an entity acts as a DHCP client and requests This mode is used when an entity acts as a DHCP client and requests
available DHCP servers to assign one or more MAC addresses (an available DHCP servers to assign one or more addresses (an address
address block), to be then assigned for use to the final end-devices. block), to be then assigned for use to the final end-devices. One
One relevant example of scenario of application of this mode is large relevant example of scenario of application of this mode is large
scale virtualization. In such environments the governing entity is scale virtualization. In such environments the governing entity is
often called a hypervisor and is frequently required to spawn new often called a hypervisor and is frequently required to spawn new
VMs. The hypervisor needs to assign new MAC addresses to those VMs. The hypervisor needs to assign new addresses to those machines.
machines. The hypervisor does not use those addresses for itself, The hypervisor does not use those addresses for itself, but rather
but rather uses them to create new VMs with appropriate MAC uses them to create new VMs with appropriate addresses. It is worth
addresses. It is worth pointing out the cumulative nature of this pointing out the cumulative nature of this scenario. Over time, the
scenario. Over time, the hypervisor is likely to increase its MAC hypervisor is likely to increase its addresses usage. Some obsolete
addresses usage. While some obsolete VMs will be deleted and their VMs will be deleted and their addresses will be eligible for reuse
MAC addresses will become eligible for release or reuse, it is for new VMs.
unexpected for all MAC addresses to be released.
4.2. Direct client mode scenario 4.2. Direct client mode scenario
This mode is used when an entity acts as a DHCP client and requests This mode is used when an entity acts as a DHCP client and requests
available DHCP servers to assign one or more MAC addresses (an available DHCP servers to assign one or more addresses (an address
address block) for its own use. This usage scenario is related to block) for its own use. This usage scenario is related to IoT
IoT (Internet of Things). With the emergence of IoT, a new class of (Internet of Things). With the emergence of IoT, a new class of
cheap, sometimes short lived and disposable devices, has emerged. cheap, sometimes short lived and disposable devices, has emerged.
Examples may include various sensors (e.g. medical) and actuators or Examples may include various sensors (e.g. medical) and actuators or
controllable LED lights. Upon first boot, the device uses a controllable LED lights. Upon first boot, the device uses a
temporary MAC address, as described in [IEEE-802.11-02-109r0], to temporary address, as described in [IEEE-802.11-02-109r0], to send
send initial DHCP packets to available DHCP servers. Then, such initial DHCP packets to available DHCP servers. Then, such devices
devices would typically request a single MAC address for each would typically request a single address for each available network
available network interface, which typically means one MAC address interface, which typically means one address per device. Once the
per device. Once the server assigns a MAC address, the device server assigns a address, the device abandons its temporary address
abandons its temporary MAC address and uses the assigned (leased) MAC and uses the assigned (leased) address.
address.
Note that a client that operates as above that does not have a 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 globally unique link-layer address on any of its interfaces MUST NOT
use a DUID-LLT or DUID-LL (link-layer based DUID). For more details, use a link-layer based DUID (DHCP Unique Identifier), i.e., DUID-LLT
refer to Section 11 of [RFC8415]. or DUID-LL. For more details, refer to Section 11 of [RFC8415].
4.3. Mechanism Overview 4.3. Mechanism Overview
In all scenarios the protocol operates in fundamentally the same way. In all scenarios the protocol operates in fundamentally the same way.
The device requesting an address, acting as a DHCP client, will send 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. 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- 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 layer-type and link-layer-len and may specify a specific address or
address block as a hint for the server. Each available server address block as a hint for the server. Each available server
responds with an Advertise message with offered link-layer address or responds with an Advertise message with offered address or addresses.
addresses. The client then picks the best server, as governed by The client then picks the best server, as governed by [RFC8415], and
[RFC8415], and will send a Request message. The target server will will send a Request message. The target server will then assign the
then assign the link-layer addresses and send a Reply message. Upon addresses and send a Reply message. Upon reception, the client can
reception, the client can start using those link-layer addresses. start using those addresses.
Normal DHCP mechanisms are in use. The client is expected to Normal DHCP mechanisms are in use. The client is expected to
periodically renew the link-layer addresses as governed by T1 and T2 periodically renew the addresses as governed by T1 and T2 timers.
timers. This mechanism can be administratively disabled by the This mechanism can be administratively disabled by the server sending
server sending "infinity" as the T1 and T2 values (see Section 7.7 of "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]).
[RFC8415]).
The client can release link-layer addresses when they are no longer The client can release addresses when they are no longer needed by
needed by sending a Release message (see Section 18.2.7 of sending a Release message (see Section 18.2.7 of [RFC8415]).
[RFC8415]).
Figure 1, taken from [RFC8415], shows a timeline diagram of the Figure 1, taken from [RFC8415], shows a timeline diagram of the
messages exchanged between a client and two servers for the typical messages exchanged between a client and two servers for the typical
lifecycle of one or more leases lifecycle of one or more leases
Server Server Server Server
(not selected) Client (selected) (not selected) Client (selected)
v v v v v v
| | | | | |
| Begins initialization | | Begins initialization |
| | | | | |
start of | _____________/|\_____________ | start of | _____________/|\_____________ |
4-message |/ Solicit | Solicit \| 4-message |/ Solicit | Solicit \|
exchange | | | exchange | | |
Determines | Determines Determines | Determines
skipping to change at page 7, line 41 skipping to change at page 7, line 35
Devices supporting this proposal MAY support the reconfigure Devices supporting this proposal MAY support the reconfigure
mechanism, as defined in Section 18.2.11 of [RFC8415]. If supported mechanism, as defined in Section 18.2.11 of [RFC8415]. If supported
by both server and client, this mechanism allows the administrator to by both server and client, this mechanism allows the administrator to
immediately notify clients that the configuration has changed and immediately notify clients that the configuration has changed and
triggers retrieval of relevant changes immediately, rather than after triggers retrieval of relevant changes immediately, rather than after
the T1 timer elapses. Since this mechanism requires implementation the T1 timer elapses. Since this mechanism requires implementation
of Reconfigure Key Authentication Protocol (See Section 20.4 of of Reconfigure Key Authentication Protocol (See Section 20.4 of
[RFC8415]), small footprint devices may choose to not support it. [RFC8415]), small footprint devices may choose to not support it.
DISCUSSION: A device may send its link-layer address in a LLADDR
option to ask the server to register that address to the client (if
available), making the assignment permanent for the lease duration.
The client MUST be prepared to use a different address if the server
chooses not to honor its hint.
5. Design Assumptions 5. Design Assumptions
One of the essential aspects of this mechanism is its cumulative One of the essential aspects of this mechanism is its cumulative
nature, especially in the hypervisor scenario. The server-client nature, especially in the hypervisor scenario. The server-client
relationship does not look like other DHCP transactions. This is relationship does not look like other DHCP transactions. This is
especially true in the hypervisor scenario. In a typical especially true in the hypervisor scenario. In a typical
environment, there would be one server and a rather small number of environment, there would be one server and a rather small number of
hypervisors, possibly even only one. However, over time the number hypervisors, possibly even only one. However, over time the number
of MAC addresses requested by the hypervisor(s) will likely increase of addresses requested by the hypervisor(s) will likely increase as
as new VMs are spawned. new VMs are spawned.
Another aspect crucial for efficient design is the observation that a Another aspect crucial for efficient design is the observation that a
single client acting as hypervisor will likely use thousands of single client acting as hypervisor will likely use thousands of
addresses. Therefore an approach similar to what is used for address addresses. Therefore an approach similar to what is used for IPv6
or prefix assignment (IA container with all assigned addresses address or prefix assignment (IA container with all assigned
listed, one option for each address) would not work well. Therefore addresses listed, one option for each address) would not work well.
the mechanism should operate on address blocks, rather than single Therefore the mechanism should operate on address blocks, rather than
values. A single address can be treated as an address block with single values. A single address can be treated as an address block
just one address. with just one address.
The DHCPv6 mechanisms are reused to large degree, including message The DHCP mechanisms are reused to large degree, including message and
and option formats, transmission mechanisms, relay infrastructure and option formats, transmission mechanisms, relay infrastructure and
others. However, a device wishing to support only link-layer address others. However, a device wishing to support only link-layer address
assignment is not required to support full DHCPv6. In other words, assignment is not required to support full DHCP. In other words, the
the device may support only assignment of link-layer addresses, but device may support only assignment of link-layer addresses, but not
not IPv6 addresses or prefixes. IPv6 addresses or prefixes.
6. Information Encoding 6. Information Encoding
A client MUST send a LLADDR option encapsulated in an IA_LL option to 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- specify the link-layer-type and link-layer-len values. For link-
layer-type 1 (Ethernet / IEEE 802 48-bit MAC addresses), a client layer-type 1 (Ethernet / IEEE 802 48-bit MAC addresses), a client
sets the link-layer-address field to: sets the link-layer-address field to:
1. 00:00:00:00:00:00 (all zeroes) if the client has no hint as to 1. 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 the starting address of the unicast address block. This address
skipping to change at page 8, line 47 skipping to change at page 8, line 36
with the specified address with the specified address
A client sets the extra-addresses field to either 0 for a single 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. 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 A client SHOULD set the valid-lifetime field to 0 (this field MUST be
ignored by the server). ignored by the server).
7. Requesting Addresses 7. Requesting Addresses
The link-layer addresses are assigned in blocks. The smallest block The addresses are assigned in blocks. The smallest block is a single
is a single address. To request an assignment, the client sends a address. To request an assignment, the client sends a Solicit
Solicit message with an IA_LL option in the message. The IA_LL message with an IA_LL option in the message. The IA_LL option MUST
option MUST contain a LLADDR option as specified in Section 6. contain a LLADDR option as specified in Section 6.
The server, upon receiving an IA_LL option, inspects its content and The server, upon receiving an IA_LL option, inspects its content and
may offer an address or addresses for each LLADDR option according to may offer an address or addresses for each LLADDR option according to
its policy. The server MAY take into consideration the address block its policy. The server MAY take into consideration the address block
requested by the client in the LLADDR option. However, the server requested by the client in the LLADDR option. However, the server
MAY chose to ignore some or all parameters of the requested address MAY chose to ignore some or all parameters of the requested address
block. In particular, the server may send a different starting block. In particular, the server may send a different starting
address than requested, or grant a smaller number of addresses than address than requested, or grant a smaller number of addresses than
requested. The server sends back an Advertise message an IA_LL requested. The server sends back an Advertise message an IA_LL
option containing an LLADDR option that specifies the addresses being option containing an LLADDR option that specifies the addresses being
skipping to change at page 10, line 7 skipping to change at page 9, line 41
A client that has included a Rapid Commit option in the Solicit, may 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 receive a Reply in response to the Solicit and skip the Advertise and
Request steps above (see Section 18.2.1 of [RFC8415]). Request steps above (see Section 18.2.1 of [RFC8415]).
A client that changes its link-layer address on an interface SHOULD A client that changes its link-layer address on an interface SHOULD
follow the recommendations in Section 7.2.6 of [RFC4861] to inform follow the recommendations in Section 7.2.6 of [RFC4861] to inform
its neighbors of the new link-layer address quickly. its neighbors of the new link-layer address quickly.
8. Renewing Addresses 8. Renewing Addresses
Address renewals follow the normal DHCPv6 renewals processing Address renewals follow the normal DHCP renewals processing described
described in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, the
the client starts sending Renew messages with the IA_LL option client starts sending Renew messages with the IA_LL option containing
containing a LLADDR option for the address block being renewed. The a LLADDR option for the address block being renewed. The server
server responds with a Reply message that contains the renewed responds with a Reply message that contains the renewed address
address block. The server SHOULD NOT alter the address block being block. The server MUST NOT shrink or expand the address block - once
renewed, unless its policy has changed. The server MUST NOT shrink a block is assigned and has a non-zero valid lifetime, its size,
or expand the address block - once a block is assigned and has a non- starting address, and ending address MUST NOT change.
zero valid lifetime, its size, starting address, and ending address
MUST NOT change.
If the requesting client needs additional MAC addresses -- e.g., in If the requesting client needs additional addresses -- e.g., in the
the hypervisor scenario because addresses need to be assigned to new hypervisor scenario because addresses need to be assigned to new VMs
VMs -- the simpler approach is for the requesting device to keep the -- the simpler approach is for the requesting device to keep the
address blocks as atomic once "leased". Therefore, if a client wants 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 more addresses at a later stage, it SHOULD send an IA_LL option with
a different IAID to create another "container" for more addresses. a different IAID to create another "container" for more addresses.
If the client is unable to Renew before the T2 timer elapses, it If the client is unable to Renew before the T2 timer elapses, it
starts sending Rebind messages as described in 18.2.5 of [RFC8415]. starts sending Rebind messages as described in 18.2.5 of [RFC8415].
9. Releasing Addresses 9. Releasing Addresses
The client may decide to release a leased address block. A client The client may decide to release a leased address block. A client
MUST release the whole block in its entirety. A client releases an MUST release the whole block in its entirety. A client releases an
address block by sending a Release message that includes the IA_LL address block by sending a Release message that includes the IA_LL
option containing the LLADDR option for the address block to release. option containing the LLADDR option for the address block to release.
The Release transmission mechanism is described in Section 18.2.7 of The Release transmission mechanism is described in Section 18.2.7 of
[RFC8415]. [RFC8415].
10. Option Definitions 10. Option Definitions
This mechanism uses an approach similar to the existing mechanisms in This mechanism uses an approach similar to the existing mechanisms in
DHCP. There is one container option (the IA_LL option) that contains DHCP. There is one container option (the IA_LL option) that contains
the actual link-layer address or addresses, represented by an LLADDR the actual address or addresses, represented by an LLADDR option.
option. Each such option represents an address block, which is Each such option represents an address block, which is expressed as a
expressed as a first address with a number that specifies how many first address with a number that specifies how many additional
additional addresses are included. addresses are included.
10.1. Identity Association for Link-Layer Addresses Option 10.1. Identity Association for Link-Layer Addresses Option
The Identity Association for Link-Layer Addresses option (IA_LL The Identity Association for Link-Layer Addresses option (IA_LL
option) is used to carry one or more IA_LL options, the parameters 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 associated with the IA_LL, and the address blocks associated with the
IA_LL. IA_LL.
The format of the IA_LL option is: The format of the IA_LL option is:
skipping to change at page 13, line 44 skipping to change at page 13, line 44
LLaddr-options field. Assuming a typical link-layer LLaddr-options field. Assuming a typical link-layer
address of 6 is used and there are no extra options, address of 6 is used and there are no extra options,
length should be equal to 18. length should be equal to 18.
link-layer-type The link-layer type MUST be a valid hardware type link-layer-type The link-layer type MUST be a valid hardware type
assigned by the IANA, as described in [RFC5494] and assigned by the IANA, as described in [RFC5494] and
in the "Hardware Types" table at in the "Hardware Types" table at
https://www.iana.org/assignments/arp-parameters. A https://www.iana.org/assignments/arp-parameters. A
2-octet field containing an unsigned integer. 2-octet field containing an unsigned integer.
link-layer-len Specifies the length of the link-layer-address field link-layer-len Specifies the length, in octets, of the link-layer-
(typically 6, for a link-layer-type of 1 (Ethernet)). address field (typically 6, for a link-layer-type of
A 2-octet field containing an unsigned integer. 1 (Ethernet)). A 2-octet field containing an
unsigned integer.
link-layer-address Specifies the link-layer address that is being link-layer-address Specifies the link-layer address that is being
requested or renewed, or a special value to request requested or renewed, or a special value to request
any address. For a link-layer type of 1 (Ethernet / any address. For a link-layer type of 1 (Ethernet /
IEEE 802 48-bit MAC addresses), see Section 6 for IEEE 802 48-bit MAC addresses), see Section 6 for
details on these values. In responses from a server, details on these values. In responses from a server,
this value specifies the first address allocated. this value specifies the first address allocated.
extra-addresses Number of additional addresses that follow the extra-addresses Number of additional addresses that follow the
address specified in link-layer-address. For a address specified in link-layer-address. For a
single address, 0 is used. For example: link-layer- single address, 0 is used. For example: link-layer-
address: 02:04:06:08:0a and extra-addresses 3 address: 02:04:06:08:0a and extra-addresses 3
designates a block of 4 addresses, starting from designates a block of 4 addresses, starting from
02:04:06:08:0a (inclusive) and ending with 02:04:06:08:0a and ending with 02:04:06:08:0d
02:04:06:08:0d (inclusive). In responses from a (inclusive). In responses from a server, this value
server, this value specifies the number of additional specifies the number of additional addresses
addresses allocated. A 4-octet field containing an allocated. A 4-octet field containing an unsigned
unsigned integer. integer.
valid-lifetime The valid lifetime for the address(es) in the option, valid-lifetime The valid lifetime for the address(es) in the option,
expressed in units of seconds. A 4-octet field expressed in units of seconds. A 4-octet field
containing an unsigned integer. containing an unsigned integer.
LLaddr-options Any encapsulated options that are specific to this LLaddr-options Any encapsulated options that are specific to this
particular address block. Currently there are no particular address block. Currently there are no
such options defined, but there may be in the future. such options defined, but there may be in the future.
In a message sent by a client to a server, the valid lifetime field In a message sent by a client to a server, the valid lifetime field
skipping to change at page 15, line 33 skipping to change at page 15, line 34
following data when adding the option to the registry: following data when adding the option to the registry:
Value: tbd2 Value: tbd2
Description: OPTION_LLADDR Description: OPTION_LLADDR
Client ORO: No Client ORO: No
Singleton Option: No Singleton Option: No
Reference: this document Reference: this document
13. Security Considerations 13. Security Considerations
See [RFC8415] for the DHCPv6 security considerations. See [RFC8200] See [RFC8415] for the DHCP security considerations. See [RFC8200]
for the IPv6 security considerations. for the IPv6 security considerations.
There is a possibility of the same link-layer address being used by 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 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 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 server. It is also possible that a bad actor purposely uses a
device's link-layer address. device's link-layer address.
14. Privacy Considerations 14. Privacy Considerations
See [RFC8415] for the DHCPv6 privacy considerations. See [RFC8415] for the DHCP privacy considerations.
For a client requesting a link-layer address directly from a server, For a client requesting a link-layer address directly from a server,
as the link-layer address assigned to a client will likely be used by as the address assigned to a client will likely be used by the client
the client to communicate on the link, the address will be exposed to to communicate on the link, the address will be exposed to those able
those able to listen in on this communication. For those peers on to listen in on this communication. For those peers on the link that
the link that are able to listen in on the DHCPv6 exchange, they are able to listen in on the DHCP exchange, they would also be able
would also be able to correlate the client's identity (based on the to correlate the client's identity (based on the DUID used) with the
DUID used) with the assigned address. Additional mechanisms, such as assigned address. Additional mechanisms, such as the ones described
the ones described in [RFC7844] can also be used. in [RFC7844] can also be used.
15. Acknowledgements 15. Acknowledgements
Thanks to the DHC Working Group participants that reviewed this Thanks to the DHC Working Group participants that reviewed this
document, provided comments, and support. With special thanks to Ian document, provided comments, and support. With special thanks to Ian
Farrer for his thorough reviews and shepherding of this document Farrer for his thorough reviews and shepherding of this document
through the IETF process. through the IETF process.
16. References 16. References
skipping to change at page 16, line 46 skipping to change at page 16, line 49
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
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>.
16.2. Informative References 16.2. Informative References
[I-D.ietf-dhc-slap-quadrant] [I-D.ietf-dhc-slap-quadrant]
Bernardos, C. and A. Mourad, "SLAP quadrant selection Bernardos, C. and A. Mourad, "SLAP quadrant selection
options for DHCPv6", draft-ietf-dhc-slap-quadrant-06 (work options for DHCPv6", draft-ietf-dhc-slap-quadrant-07 (work
in progress), March 2020. in progress), April 2020.
[IEEE-802-Tutorial] [IEEE-802-Tutorial]
Thaler, P., "Emerging IEEE 802 Work on MAC Addressing", Thaler, P., "Emerging IEEE 802 Work on MAC Addressing",
<https://datatracker.ietf.org/meeting/96/materials/slides- <https://datatracker.ietf.org/meeting/96/materials/slides-
96-edu-ieee802work-0/>. 96-edu-ieee802work-0/>.
[IEEE-802.11-02-109r0] [IEEE-802.11-02-109r0]
Edney, J., Haverinen, H., Honkanen, J-P., and P. Orava, Edney, J., Haverinen, H., Honkanen, J-P., and P. Orava,
"Temporary MAC address for anonymity", "Temporary MAC address for anonymity",
<https://mentor.ieee.org/802.11/dcn/02/11-02-0109-00-000i- <https://mentor.ieee.org/802.11/dcn/02/11-02-0109-00-000i-
skipping to change at page 17, line 43 skipping to change at page 17, line 43
DOI 10.17487/RFC7844, May 2016, DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/info/rfc7844>. <https://www.rfc-editor.org/info/rfc7844>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
Appendix A. IEEE 802c Summary Appendix A. IEEE 802c Summary
This appendix provides a brief summary of IEEE802c from This appendix provides a brief summary of IEEE 802c from
[IEEEStd802c-2017]. [IEEEStd802c-2017].
The original IEEE 802 specifications assigned half of the 48-bit MAC 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 address space to local use -- these addresses have the U/L bit set to
1 and are locally administered with no imposed structure. 1 and are locally administered with no imposed structure.
In 2017, the IEEE issued the 802c specification which defines a new In 2017, the IEEE issued the 802c specification 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
local MAC address space." Under this plan, there are 4 SLAP local MAC address space." Under this plan, there are 4 SLAP
 End of changes. 37 change blocks. 
111 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/