Link-Layer Address Assignment Mechanism for DHCPv6
RFC 8947
|
Document |
Type |
|
RFC - Proposed Standard
(December 2020; No errata)
|
|
Authors |
|
Bernie Volz
,
Tomek Mrugalski
,
Carlos Bernardos
|
|
Last updated |
|
2020-12-01
|
|
Replaces |
|
draft-bvtm-dhc-mac-assign
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
xml
pdf
htmlized
bibtex
|
|
Reviews |
|
|
Stream |
WG state
|
|
Submitted to IESG for Publication
(wg milestone:
Nov 2019 - WGLC Link-Layer Addr...
)
|
|
Document shepherd |
|
Ian Farrer
|
|
Shepherd write-up |
|
Show
(last changed 2020-04-16)
|
IESG |
IESG state |
|
RFC 8947 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Yes
|
|
Telechat date |
|
|
|
Responsible AD |
|
Éric Vyncke
|
|
IESG note |
|
For information, this MAC-assign document is linked to draft-ietf-dhc-slap-quadrant-08 (currently in IETF Last call). Probably better to read them in a row: first MAC assign then SLAP.
|
|
Send notices to |
|
Tomek Mrugalski <tomasz.mrugalski@gmail.com>, Ian Farrer <ianfarrer@gmx.com>
|
IANA |
IANA review state |
|
Version Changed - Review Needed
|
|
IANA action state |
|
RFC-Ed-Ack
|
|
IANA expert review state |
|
Expert Reviews OK
|
Internet Engineering Task Force (IETF) B. Volz
Request for Comments: 8947 Cisco
Category: Standards Track T. Mrugalski
ISSN: 2070-1721 ISC
CJ. Bernardos
UC3M
December 2020
Link-Layer Address Assignment Mechanism for DHCPv6
Abstract
In certain environments, e.g., large-scale virtualization
deployments, new devices are created in an automated manner. Such
devices may have their link-layer addresses assigned in an automated
fashion. With sufficient scale, the likelihood of a collision using
random assignment without duplication detection is not acceptable.
Therefore, an allocation mechanism is required. This document
proposes an extension to DHCPv6 that allows a scalable approach to
link-layer address assignments where preassigned link-layer address
assignments (such as by a manufacturer) are not possible or are
unnecessary.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8947.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
2. Requirements Language
3. Terminology
4. Deployment Scenarios
4.1. Scenario: Proxy Client Mode
4.2. Scenario: Direct Client Mode
5. Mechanism Overview
6. Design Assumptions
7. Information Encoding
8. Requesting Addresses
9. Renewing Addresses
10. Releasing Addresses
11. Option Definitions
11.1. Identity Association for Link-Layer Addresses Option
11.2. Link-Layer Addresses Option
12. Selecting Link-Layer Addresses for Assignment to an IA_LL
13. IANA Considerations
14. Security Considerations
15. Privacy Considerations
16. References
16.1. Normative References
16.2. Informative References
Appendix A. IEEE 802c Summary
Acknowledgments
Authors' Addresses
1. Introduction
There are several deployment types that deal with a large number of
devices that need to be initialized. One of them is a scenario where
virtual machines (VMs) are created on a massive scale. Typically,
the new VM instances are assigned a link-layer address, but random
assignment does not scale well due to the risk of a collision (see
Appendix A.1 of [RFC4429]). Another use case is Internet of Things
(IoT) devices (see [RFC7228]). The huge number of such devices could
strain the IEEE's available Organizationally Unique Identifier (OUI)
global address space. While there is typically no need to provide
global link-layer address uniqueness for such devices, a link-layer
assignment mechanism allows for conflicts to be avoided inside an
administrative domain. For those reasons, it is desired to have some
form of mechanism that would be able to assign locally unique Media
Access Control (MAC) addresses.
This document proposes a new mechanism that extends DHCPv6 operation
to handle link-layer address assignments.
Since DHCPv6 [RFC8415] is a protocol that can allocate various types
of resources (non-temporary addresses, temporary addresses, prefixes,
as well as many options) and has the necessary infrastructure to
maintain such allocations (numerous server and client
implementations, large deployed relay infrastructure, and supportive
solutions such as leasequery and failover), it is a good candidate to
address the desired functionality.
While this document presents a design that should be usable for any
link-layer address type, some of the details are specific to IEEE 802
Show full document text