draft-ietf-dhc-mac-assign-06.txt   draft-ietf-dhc-mac-assign-07.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: November 5, 2020 ISC Expires: December 4, 2020 ISC
CJ. Bernardos CJ. Bernardos
UC3M UC3M
May 4, 2020 June 2, 2020
Link-Layer Addresses Assignment Mechanism for DHCPv6 Link-Layer Addresses Assignment Mechanism for DHCPv6
draft-ietf-dhc-mac-assign-06 draft-ietf-dhc-mac-assign-07
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 November 5, 2020. This Internet-Draft will expire on December 4, 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 . . . . . . . . . . . . . . . . . . . . . 9 8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 16
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
16.1. Normative References . . . . . . . . . . . . . . . . . . 16 16.1. Normative References . . . . . . . . . . . . . . . . . . 16
16.2. Informative References . . . . . . . . . . . . . . . . . 16 16.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 17 Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
There are several new deployment types that deal with a large number 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 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 (Internet of Things) devices (see [RFC7228]).
would likely exhaust a vendor's OUI (Organizationally Unique The huge number of such devices would likely exhaust a vendor's OUI
Identifier) global address space, and while there is typically no (Organizationally Unique Identifier) global address space, and while
need to provide global uniqueness for such devices, a link-layer there is typically no need to provide global uniqueness for such
assignment mechanisms allows for conflicts to be avoided inside an devices, a link-layer assignment mechanism allows for conflicts to be
administrative domain. For those reasons, it is desired to have some avoided inside an administrative domain. For those reasons, it is
form of authority that would be able to assign locally unique MAC desired to have some form of authority that would be able to assign
addresses. locally unique MAC 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, as well as many options) and has the necessary
(numerous server and client implementations, large deployed relay infrastructure to maintain such allocations (numerous server and
infrastructure, supportive solutions, like leasequery and failover) client implementations, large deployed relay infrastructure, and
to maintain such assignment, it is a good candidate to address the supportive solutions such as leasequery and failover), it is a good
desired functionality. candidate to address the desired functionality.
While this document presents a design that should be usable for any While this document presents a design that should be usable for any
link-layer address type, some of the details are specific to Ethernet link-layer address type, some of the details are specific to Ethernet
/ IEEE 802 48-bit MAC addresses. Future documents may provide / IEEE 802 48-bit MAC addresses. Future documents may provide
specifics for other link-layer address types. specifics for other link-layer address types.
The IEEE originally set aside half of the 48-bit MAC Address space 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 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 published an optional specification ([IEEEStd802c-2017]) that divides
space into quadrants (Standards Assigned Identifier, Extended Local this space into quadrants (Standards Assigned Identifier, Extended
Identifier, Administratively Assigned Identifier, and a Reserved Local Identifier, Administratively Assigned Identifier, and a
quadrant) - more details are in Appendix A. Reserved quadrant) - more details are in Appendix A.
The IEEE is also working to specify protocols and procedures for The IEEE is also working to specify protocols and procedures for
assignment of locally unique addresses (IEEE 802.1cq). This work may assignment of locally unique addresses (IEEE 802.1cq). This work may
serve as one such protocol for assignment. For additional serve as one such protocol for assignment. For additional
background, see [IEEE-802-Tutorial]. background, see [IEEE-802-Tutorial].
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 DHCP terminology relevant to this specification from [RFC8415] The DHCP terminology relevant to this specification from [RFC8415]
applies here. applies here.
client A device 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) specified
in this document. The client may or may not support
IPv6 address assignment and prefix delegation as
specified in [RFC8415].
server Software 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].
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 IEEE 802. 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.
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 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 addresses (an address available DHCP servers to assign one or more addresses (an address
block), to be then assigned for use to the final end-devices. One block), to be then assigned for use by the final end-devices. Large-
relevant example of scenario of application of this mode is large scale virtualization is one application scenario for proxy client
scale virtualization. In such environments the governing entity is mode. In such environments the governing entity is often called a
often called a hypervisor and is frequently required to spawn new hypervisor and is frequently required to spawn new VMs. The
VMs. The hypervisor needs to assign new addresses to those machines. hypervisor needs to assign new addresses to those machines. The
The hypervisor does not use those addresses for itself, but rather hypervisor does not use those addresses for itself, but rather uses
uses them to create new VMs with appropriate addresses. It is worth them to create new VMs with appropriate addresses. It is worth
pointing out the cumulative nature of this scenario. Over time, the pointing out the cumulative nature of this scenario. Over time, the
hypervisor is likely to increase its addresses usage. Some obsolete hypervisor is likely to increase its address usage. Some obsolete
VMs will be deleted and their addresses will be eligible for reuse VMs will be deleted and their addresses will be eligible for reuse
for new VMs. for new VMs.
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 can be used when an entity acts as a DHCP client and
available DHCP servers to assign one or more addresses (an address requests available DHCP servers to assign one or more addresses (an
block) for its own use. This usage scenario is related to IoT address block) for its use. This usage scenario is related to IoT,
(Internet of Things). With the emergence of IoT, a new class of as described earlier (see Section 1). Upon first boot, the device
cheap, sometimes short lived and disposable devices, has emerged. uses a temporary address, as described in [IEEE-802.11-02-109r0], to
Examples may include various sensors (e.g. medical) and actuators or send initial DHCP packets to available DHCP servers. Then, such
controllable LED lights. Upon first boot, the device uses a devices would typically request a single address for each available
temporary address, as described in [IEEE-802.11-02-109r0], to send network interface, which typically means one address per device.
initial DHCP packets to available DHCP servers. Then, such devices Once the server assigns an address, the device abandons its temporary
would typically request a single address for each available network address and uses the assigned (leased) address.
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 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 link-layer based DUID (DHCP Unique Identifier), i.e., DUID-LLT use a link-layer based DUID (DHCP Unique Identifier), i.e., DUID-LLT
or DUID-LL. For more details, refer to Section 11 of [RFC8415]. or DUID-LL, for its client identifier. As of this writing, this
means such a device MUST use a DUID-EN or DUID-UUID (though new DUID
types may be defined in the future). 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 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 address or addresses. responds with an Advertise message with offered address or addresses.
skipping to change at page 7, line 23 skipping to change at page 7, line 34
and two servers for the typical lifecycle of one or more leases and two servers for the typical lifecycle of one or more leases
Confirm, Decline, and Information-Request messages are not used in Confirm, Decline, and Information-Request messages are not used in
link-layer address assignment. link-layer address assignment.
Clients implementing this mechanism SHOULD use the Rapid Commit Clients implementing this mechanism SHOULD use the Rapid Commit
option as specified in Section 5.1 and 18.2.1 of [RFC8415]. option as specified in Section 5.1 and 18.2.1 of [RFC8415].
An administrator may make the address assignment permanent by An administrator may make the address assignment permanent by
specifying use of infinite lifetimes, as defined in Section 7.7 of specifying use of infinite lifetimes, as defined in Section 7.7 of
[RFC8415]. An administrator may also disable the need for the [RFC8415].
renewal mechanism by setting the T1 and T2 values to infinity.
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.
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 addresses requested by the hypervisor(s) will likely increase as of addresses requested by the hypervisor(s) will likely increase as
skipping to change at page 8, line 29 skipping to change at page 8, line 39
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
has the IEEE 802 individual/group bit set to 0 (individual). has the IEEE 802 individual/group bit set to 0 (individual).
2. Any other value to request a specific block of address starting 2. Any other value to request a specific block of address starting
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 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 addresses are assigned in blocks. The smallest block is a single The addresses are assigned in blocks. The smallest block is a single
address. To request an assignment, the client sends a Solicit address. To request an assignment, the client sends a Solicit
message with an IA_LL option in the message. The IA_LL option MUST message with an IA_LL option in the message. The IA_LL option MUST
contain a LLADDR option as specified in Section 6. contain a LLADDR option as specified in Section 6.
skipping to change at page 9, line 9 skipping to change at page 9, line 20
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
offered. If the server is unable to provide any addresses it MUST offered. If the server is unable to provide any addresses it MUST
return the IA_LL option containing a Status Code option (see return the IA_LL option containing a Status Code option (see
Section 21.13 of [RFC8415]) with status set to NoAddrsAvail. Section 21.13 of [RFC8415]) with status set to NoAddrsAvail.
The client MUST be able to handle an Advertise message containing a The client MUST be able to handle an Advertise message containing a
smaller number of addresses, or an address or addresses different smaller number of addresses, or an address or addresses different
than those requested. from those requested.
The client waits for available servers to send Advertise responses The client waits for available servers to send Advertise responses
and picks one server as defined in Section 18.2.9 of [RFC8415]. The 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 client then sends a Request message that includes the IA_LL container
option with the LLADDR option copied from the Advertise message sent option with the LLADDR option copied from the Advertise message sent
by the chosen server. by the chosen server.
Upon reception of a Request message with IA_LL container option, the Upon reception of a Request message with IA_LL container option, the
server assigns requested addresses. The server allocates block of server assigns requested addresses. The server allocates block of
addresses according to its configured policy. The server MAY assign addresses according to its configured policy. The server MAY assign
a different block than requested in the Request message. It then a different block than requested in the Request message. It then
generates and sends a Reply message back to the client. generates and sends a Reply message back to the client.
Upon receiving a Reply message, the client parses the IA_LL container Upon receiving a Reply message, the client parses the IA_LL container
option and may start using all provided addresses. It MUST restart 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. 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 The client MUST be able to handle a Reply message containing a
smaller number of addresses, or an address or addresses different smaller number of addresses, or an address or addresses different
than those requested. from those requested.
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
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3
| OPTION_IA_LL | option-len | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) | | OPTION_IA_LL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 (4 octets) | | IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 (4 octets) | | T1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . | T2 (4 octets) |
. IA_LL-options . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . IA_LL-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IA_LL Option Format Figure 2: IA_LL Option Format
option-code OPTION_IA_LL (tbd1). option-code OPTION_IA_LL (tbd1).
option-len 12 + length of IA_LL-options field. option-len 12 + length of IA_LL-options field.
IAID The unique identifier for this IA_LL; the IAID must IAID The unique identifier for this IA_LL; the IAID must
be unique among the identifiers for all of this be unique among the identifiers for all of this
client's IA_LLs. The number space for IA_LL IAIDs is client's IA_LLs. The number space for IA_LL IAIDs is
skipping to change at page 13, line 9 skipping to change at page 13, line 9
10.2. Link-Layer Addresses Option 10.2. Link-Layer Addresses Option
The Link-Layer Addresses option is used to specify an address block The Link-Layer Addresses option is used to specify an address block
associated with a IA_LL. The option must be encapsulated in the 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 IA_LL-options field of an IA_LL option. The LLaddr-options fields
encapsulates those options that are specific to this address block. encapsulates those options that are specific to this address block.
The format of the Link-Layer Addresses option is: The format of the Link-Layer Addresses option is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LLADDR | option-len | | OPTION_LLADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-layer-type | link-layer-len | | link-layer-type | link-layer-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. link-layer-address . . link-layer-address .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extra-addresses | | extra-addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime | | valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. LLaddr-options . . LLaddr-options .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: LLADDR Option Format Figure 3: LLADDR Option Format
option-code OPTION_LLADDR (tbd2). option-code OPTION_LLADDR (tbd2).
option-len 12 + link-layer-len field (typically 6) + length of option-len 12 + link-layer-len field (typically 6) + length of
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.
skipping to change at page 15, line 34 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 DHCP security considerations. See [RFC8200] See [RFC8415] and [RFC7227] for the DHCP security considerations.
for the IPv6 security considerations. See [RFC8200] 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 an address from the space assigned to the DHCP server.
server. It is also possible that a bad actor purposely uses a Note that this issue would exist on these networks even if DHCP were
device's link-layer address. not used to obtain the address. See [IEEE-802.11-02-109r0] for
techniques that can be used on 802.11 networks to probe for and avoid
collisions.
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 14. Privacy Considerations
See [RFC8415] for the DHCP 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 address assigned to a client will likely be used by the client 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 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 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 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 to correlate the client's identity (based on the DUID used) with the
assigned address. Additional mechanisms, such as the ones described assigned address. Additional mechanisms, such as 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. Thanks also to area reviewers Samita
Chakrabarti, Roni Even and Tianran Zhou, and IESG members Warren
Kumari, Barry Leiba, and Eric Vyncke for their suggestions.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 16, line 49 skipping to change at page 17, line 9
[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-07 (work options for DHCPv6", draft-ietf-dhc-slap-quadrant-09 (work
in progress), April 2020. in progress), May 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 31 skipping to change at page 17, line 38
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>. <https://www.rfc-editor.org/info/rfc2464>.
[RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines
for the Address Resolution Protocol (ARP)", RFC 5494, for the Address Resolution Protocol (ARP)", RFC 5494,
DOI 10.17487/RFC5494, April 2009, DOI 10.17487/RFC5494, April 2009,
<https://www.rfc-editor.org/info/rfc5494>. <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>.
[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 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844, Profiles for DHCP Clients", RFC 7844,
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>.
 End of changes. 29 change blocks. 
110 lines changed or deleted 146 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/