draft-ietf-dhc-mac-assign-03.txt   draft-ietf-dhc-mac-assign-04.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: July 16, 2020 ISC Expires: September 6, 2020 ISC
CJ. Bernardos CJ. Bernardos
UC3M UC3M
January 13, 2020 March 5, 2020
Link-Layer Addresses Assignment Mechanism for DHCPv6 Link-Layer Addresses Assignment Mechanism for DHCPv6
draft-ietf-dhc-mac-assign-03 draft-ietf-dhc-mac-assign-04
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 July 16, 2020. This Internet-Draft will expire on September 6, 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 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
15.1. Normative References . . . . . . . . . . . . . . . . . . 16 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
15.2. Informative References . . . . . . . . . . . . . . . . . 16 16.1. Normative References . . . . . . . . . . . . . . . . . . 16
16.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 17 Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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. Typically there is no need to Another use case is IoT devices. The huge number of such devices
provide global uniqueness of MAC addresses for such devices. On the would likely exhaust a vendor's OUI (Organizationally Unique
other hand, the huge number of such devices would likely exhaust a Identifier) global address space, and while there is typically no
vendor's OUI (Organizationally Unique Identifier) global address need to provide global uniqueness for such devices, a link-layer
space. For those reasons, it is desired to have some form of local assignment mechanisms allows for conflicts to be avoided inside an
authority that would be able to assign locally unique MAC addresses. administrative domain. For those reasons, it is desired to have some
form of local authority that would be able to assign 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, 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 5, line 15 skipping to change at page 5, line 22
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 MAC address, as described in [IEEE-802.11-02-109r0], to
send initial DHCP packets to available DHCP servers. Then, such send initial DHCP packets to available DHCP servers. Then, such
devices would typically request a single MAC address for each devices would typically request a single MAC address for each
available network interface, which typically means one MAC address available network interface, which typically means one MAC address
per device. Once the server assigns a MAC address, the device per device. Once the server assigns a MAC address, the device
abandons its temporary MAC address and uses the assigned (leased) MAC abandons its temporary MAC address and uses the assigned (leased) MAC
address. 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 DUID-LLT or DUID-LL (link-layer based DUID). 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 link-layer address or
addresses. The client then picks the best server, as governed by addresses. The client then picks the best server, as governed by
skipping to change at page 7, line 26 skipping to change at page 7, line 37
[RFC8415]. An administrator may also disable the need for the [RFC8415]. An administrator may also disable the need for the
renewal mechanism by setting the T1 and T2 values to infinity. 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 chose 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 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 option to ask the server to register that address to the client (if
available), making the assignment permanent for the lease duration. available), making the assignment permanent for the lease duration.
The client MUST be prepared to use a different address if the server The client MUST be prepared to use a different address if the server
choses not to honor its hint. 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 MAC addresses requested by the hypervisor(s) will likely increase
skipping to change at page 9, line 5 skipping to change at page 9, line 18
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
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 a response that contains an address The client MUST be able to handle an Advertise message containing a
or addresses different than those requested. smaller number of addresses, or an address or addresses different
than 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 that contains an The client MUST be able to handle a Reply message containing a
address or addresses different than those requested. 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 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]).
8. Renewing Addresses 8. Renewing Addresses
Address renewals follow the normal DHCPv6 renewals processing Address renewals follow the normal DHCPv6 renewals processing
described in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, described in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses,
the client starts sending Renew messages with the IA_LL option the client starts sending Renew messages with the IA_LL option
skipping to change at page 13, line 35 skipping to change at page 13, line 39
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.
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]. The assigned by the IANA, as described in [RFC5494] and
type is stored in network byte order. in the "Hardware Types" table at
https://www.iana.org/assignments/arp-parameters. A
2-octet field containing an unsigned integer.
link-layer-len Specifies the length of the link-layer-address field link-layer-len Specifies the length of the link-layer-address field
(typically 6, for a link-layer-type of 1 (Ethernet)). (typically 6, for a link-layer-type of 1 (Ethernet)).
A 2-octet field containing an unsigned integer. 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,
skipping to change at page 14, line 32 skipping to change at page 14, line 39
In a message sent by a server to a client, the client MUST use the 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 value in the valid lifetime field for the valid lifetime for the
address block. The value in the valid lifetime field is the number address block. The value in the valid lifetime field is the number
of seconds remaining in the lifetime. of seconds remaining in the lifetime.
As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is
taken to mean "infinity" and should be used carefully. taken to mean "infinity" and should be used carefully.
More than one LLADDR option can appear in an IA_LL option. More than one LLADDR option can appear in an IA_LL option.
11. Selecting Link Layer Addresses for Assignment to an IA_LL 11. Selecting Link-Layer Addresses for Assignment to an IA_LL
A server selects link layer addresses to be assigned to an IA_LL A server selects link-layer addresses to be assigned to an IA_LL
according to the assignment policies determined by the server according to the assignment policies determined by the server
administrator. administrator.
Link layer addresses are typically specific to a link and the server Link-layer addresses are typically specific to a link and the server
SHOULD follow the steps in Section 13.1 of [RFC8415] to determine the SHOULD follow the steps in Section 13.1 of [RFC8415] to determine the
client's link. client's link.
For Ethernet / IEEE 802 MAC addresses, a server MAY use additional For Ethernet / IEEE 802 MAC addresses, a server MAY use additional
options supplied by a relay agent or client to select the quadrant options supplied by a relay agent or client to select the quadrant
(see Appendix A) from which addresses are to be assigned. This MAY (see Appendix A) from which addresses are to be assigned. This MAY
include new options, such as those specified in include new options, such as those specified in
[I-D.ietf-dhc-slap-quadrant]. [I-D.ietf-dhc-slap-quadrant].
12. IANA Considerations 12. IANA Considerations
skipping to change at page 16, line 7 skipping to change at page 16, line 11
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 link-layer address assigned to a client will likely be used by
the client to communicate on the link, the address will be exposed to 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 those able to listen in on this communication. For those peers on
the link that are able to listen in on the DHCPv6 exchange, they the link that are able to listen in on the DHCPv6 exchange, they
would also be able to correlate the client's identity (based on the would also be able to correlate the client's identity (based on the
DUID used) with the assigned address. Additional mechanisms, such as DUID used) with the assigned address. Additional mechanisms, such as
the ones described in [RFC7844] can also be used. the ones described in [RFC7844] can also be used.
15. References 15. Acknowledgements
15.1. Normative References 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.
16. 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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
15.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-02 (work options for DHCPv6", draft-ietf-dhc-slap-quadrant-04 (work
in progress), January 2020. in progress), February 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-
 End of changes. 22 change blocks. 
32 lines changed or deleted 51 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/