doc: Add RFC documents

1 files changed, 940 insertions, 0 deletions

diff --git a/doc/rfc/rfc8947.txt b/doc/rfc/rfc8947.txt
new file mode 100644
index 0000000..ba9b810
--- /dev/null
+++ b/doc/rfc/rfc8947.txt
@@ -0,0 +1,940 @@
+
+
+
+
+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
+   48-bit MAC addresses [IEEEStd802].  Future documents may provide
+   specifics for other link-layer address types.
+
+   IEEE 802 originally set aside half of the 48-bit MAC address space
+   for local use (where the Universal/Local (U/L) bit is set to 1).  In
+   2017, IEEE published an amendment [IEEEStd802c] that divides this
+   space into quadrants with differentiated address rules.  More details
+   are in Appendix A.
+
+   IEEE is also developing protocols and procedures for assignment of
+   locally unique addresses (IEEE 802.1CQ).  This work may serve as an
+   alternative protocol for assignment.  For additional background, see
+   [IEEE-P802.1CQ-Project].
+
+2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Terminology
+
+   The DHCP terminology relevant to this specification from [RFC8415]
+   applies here.  The following definitions either modify those
+   definitions as to how they are used in this document or define new
+   terminology used herein.
+
+   address         Unless specified otherwise, a link-layer (or MAC)
+                   address, as specified in [IEEEStd802].  The address
+                   is typically six octets long, but some network
+                   architectures may use different lengths.
+
+   address block   A number of consecutive link-layer addresses.  An
+                   address block is expressed as a first address plus a
+                   number that designates the number of additional
+                   (extra) addresses.  A single address can be
+                   represented by the address itself and zero extra
+                   addresses.
+
+   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 specified in this
+                   document (IA_LL and LLADDR).  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 11.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 11.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 specified in
+                   this document (IA_LL and LLADDR).  The server may or
+                   may not support IPv6 address assignment and prefix
+                   delegation as specified in [RFC8415].
+
+4.  Deployment Scenarios
+
+   This mechanism is designed to be generic and usable in many
+   deployments, but there are two scenarios it attempts to address in
+   particular: (i) proxy client mode and (ii) direct client mode.
+
+4.1.  Scenario: Proxy Client Mode
+
+   This mode is used when an entity acts as a DHCP client that requests
+   that available DHCP servers assign one or more addresses (an address
+   block) for the DHCP client to then assign to the final end devices to
+   use.  Large-scale virtualization is one application scenario for
+   proxy client mode.  In such environments, this entity is often called
+   a "hypervisor" and is frequently required to spawn new VMs.  The
+   hypervisor needs to assign new addresses to those machines.  The
+   hypervisor does not use those addresses for itself, but rather it
+   uses them to create new VMs with appropriate addresses.  It is worth
+   pointing out the cumulative nature of this scenario.  Over time, the
+   hypervisor is likely to increase its address use.  Some obsolete VMs
+   will be deleted; their addresses are potentially eligible for reuse
+   by new VMs.
+
+4.2.  Scenario: Direct Client Mode
+
+   This mode can be used when an entity acts as a DHCP client that
+   requests that available DHCP servers assign one or more addresses (an
+   address block) for its own use.  This usage scenario is related to
+   IoT (see Section 1).  Upon first boot, for each interface, the device
+   uses a temporary address, as described in [IEEEStd802.11] and IEEE
+   802.1CQ [IEEE-P802.1CQ-Project], to send initial DHCP packets to
+   available DHCP servers wherein the device requests a single address
+   for that network interface.  Once the server assigns an address, the
+   device abandons its temporary address and uses the assigned (leased)
+   address.
+
+   Note that a client that operates as above that does not have a
+   globally unique link-layer address on any of its interfaces MUST NOT
+   use a link-layer-based DHCP Unique Identifier (DUID).  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.
+
+5.  Mechanism Overview
+
+   In the scenarios described in Section 4, the protocol operates in
+   fundamentally the same way.  The device requesting an address, acting
+   as a DHCP client, will send a Solicit message with an IA_LL option to
+   all available DHCP servers.  That IA_LL option MUST include an LLADDR
+   option specifying the link-layer-type and link-layer-len, and it may
+   include a specific address or address block as a hint for the server.
+   Each available server responds with either a Reply message with
+   committed address(es) (if Rapid Commit was requested and honored) or
+   an Advertise message with offered address(es).  The client selects a
+   server's response, as governed by [RFC8415].  If necessary, the
+   client sends a Request message; the target server will then assign
+   the address(es) and send a Reply message.  Once a Reply is received,
+   the client can start using those address(es).
+
+   Normal DHCP mechanisms are in use.  The client is expected to
+   periodically renew the addresses as governed by T1 and T2 timers and
+   to stop using the address once the valid lifetime expires.  Renewals
+   can be administratively disabled by the server sending "infinity" as
+   the T1 and T2 values (see Section 7.7 of [RFC8415]).  An
+   administrator may make the address assignment permanent by specifying
+   use of the "infinity" valid lifetime, as defined in Section 7.7 of
+   [RFC8415].
+
+   The client can release addresses when they are no longer needed by
+   sending a Release message (see Section 18.2.7 of [RFC8415]).
+
+   Figure 9 in [RFC8415] shows a timeline diagram of the messages
+   exchanged between a client and two servers for the typical life cycle
+   of one or more leases.
+
+   Confirm and Information-request messages are not used in link-layer
+   address assignment.  Decline should technically never be needed, but
+   see Section 12 for one situation where this message is needed.
+
+   Clients implementing this mechanism SHOULD use the Rapid Commit
+   option, as specified in Sections 5.1 and 18.2.1 of [RFC8415], to
+   obtain addresses with a two-message exchange when possible.
+
+   Devices supporting this proposal MAY support the reconfigure
+   mechanism, as defined in Section 18.2.11 of [RFC8415].  If supported
+   by both server and client, the reconfigure mechanism allows the
+   administrator to immediately notify clients that the configuration
+   has changed and triggers retrieval of relevant changes immediately,
+   rather than after the T1 timer elapses.  Since this mechanism
+   requires implementation of Reconfiguration Key Authentication
+   Protocol (see Section 20.4 of [RFC8415]), small-footprint devices may
+   choose not to support it.
+
+6.  Design Assumptions
+
+   One of the essential aspects of this mechanism is its cumulative
+   nature, especially in the hypervisor scenario.  The server-client
+   relationship does not look like other DHCP transactions in the
+   hypervisor scenario.  In a typical environment, there would be one
+   server and a rather small number of hypervisors, possibly even only
+   one.  However, over time, the number of addresses requested by the
+   hypervisor(s) will increase as more VMs are spawned.
+
+   Another aspect crucial for efficient design is the observation that a
+   single client acting as hypervisor will likely use thousands of
+   addresses.  An approach similar to what is used for IPv6 address or
+   prefix assignment (IA container with all assigned addresses listed,
+   one option for each address) would not work well.  Therefore, the
+   mechanism should operate on address blocks rather than single values.
+   A single address can be treated as an address block with just one
+   address.
+
+   The DHCP mechanisms are reused to a large degree, including message
+   and option formats, transmission mechanisms, relay infrastructure,
+   and others.  However, a device wishing to support only link-layer
+   address assignment is not required to support full DHCP.  In other
+   words, the device may support only assignment of link-layer addresses
+   but not IPv6 addresses or prefixes.
+
+7.  Information Encoding
+
+   A client MUST send an LLADDR option encapsulated in an IA_LL option
+   to specify the link-layer-type and link-layer-len values.  For link-
+   layer-type 1 (Ethernet) and 6 (IEEE 802 Networks), a client sets the
+   link-layer-address field to:
+
+   1.  All zeroes if the client has no hint as to the starting address
+       of the unicast address block.  This address has the IEEE 802
+       individual/group bit set to 0 (individual).
+
+   2.  Any other value to request a specific block of address starting
+       with the specified address.
+
+   Encoding information for other link-layer-types may be added in the
+   future by publishing an RFC that specifies those values.
+
+   A client sets the extra-addresses field to either 0 for a single
+   address or the size of the requested address block minus 1.
+
+   A client MUST set the valid-lifetime field to 0 (this field MUST be
+   ignored by the server).
+
+8.  Requesting Addresses
+
+   The addresses are assigned in blocks.  The smallest block is a single
+   address.  To request an assignment, the client sends a Solicit
+   message with an IA_LL option inside.  The IA_LL option MUST contain
+   an LLADDR option, as specified in Section 7.
+
+   The server, upon receiving an IA_LL option, inspects its content and
+   may offer an address or addresses for each LLADDR option according to
+   its policy.  The server MAY take into consideration the address block
+   requested by the client in the LLADDR option.  However, the server
+   MAY choose to ignore some or all parameters of the requested address
+   block.  In particular, the server may send either a different
+   starting address or a smaller number of addresses than requested.
+   The server sends back an Advertise message with an IA_LL option
+   containing an LLADDR option that specifies the addresses being
+   offered.  If the server is unable to provide any addresses, it MUST
+   return the IA_LL option containing a Status Code option (see
+   Section 21.13 of [RFC8415]) with status set to NoAddrsAvail.
+
+   Note that servers that do not support the IA_LL option will ignore
+   the option and not return it in Advertise (and Reply) messages.
+   Clients that send IA_LL options MUST treat this as if the server
+   returned the NoAddrsAvail status for these IA_LL option(s).
+
+   The client waits for available servers to send Advertise responses
+   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
+   option with the LLADDR option copied from the Advertise message sent
+   by the chosen server.
+
+   The client MUST process the address block(s) returned in the
+   Advertise, rather than what it included in the Solicit message, and
+   may consider the offered address block(s) in selecting the Advertise
+   message to accept.  The server may offer a smaller number of
+   addresses or different addresses from those requested.  A client MUST
+   NOT use resources returned in an Advertise message except to select a
+   server and in sending the Request message to that server; resources
+   are only useable by a client when returned in a Reply message.
+
+   Upon reception of a Request message with the IA_LL container option,
+   the server assigns the requested addresses.  The server allocates a
+   block of addresses according to its configured policy.  The server
+   MAY assign a different block or smaller block size than requested in
+   the Request message.  The server then generates and sends a Reply
+   message back to the client.
+
+   Upon receiving a Reply message, the client parses the IA_LL container
+   option and may start using all provided addresses.  It MUST restart
+   its T1 and T2 timers using the values specified in the IA_LL option.
+
+   The client MUST use the address block(s) returned in the Reply
+   message, which may be a smaller block(s) or may have a different
+   address(es) than requested.
+
+   A client that has included a Rapid Commit option in the Solicit
+   message may receive a Reply in response to the Solicit message and
+   skip the Advertise and Request message steps above (see
+   Section 18.2.1 of [RFC8415]).
+
+   A client that changes its link-layer address on an interface SHOULD
+   follow the recommendations in Section 7.2.6 of [RFC4861] to inform
+   its neighbors of the new link-layer address quickly.
+
+9.  Renewing Addresses
+
+   Address renewals follow the normal DHCP renewals processing described
+   in Section 18.2.4 of [RFC8415].  Once the T1 timer elapses, the
+   client starts sending Renew messages with the IA_LL option containing
+   an LLADDR option for the address block being renewed.  The server
+   responds with a Reply message that contains the renewed address
+   block.  The server MUST NOT shrink or expand the address block.  Once
+   a block is assigned and has a non-zero valid lifetime, its size,
+   starting address, and ending address MUST NOT change.
+
+   If the requesting client needs additional addresses (e.g., in the
+   hypervisor scenario because addresses need to be assigned to new
+   VMs), it MUST send an IA_LL option with a different Identity
+   Association IDentifier (IAID) to create another "container" for more
+   addresses.
+
+   If the client is unable to renew before the T2 timer elapses, it
+   starts sending Rebind messages, as described in Section 18.2.5 of
+   [RFC8415].
+
+10.  Releasing Addresses
+
+   The client may decide to release a leased address block.  A client
+   MUST release the block in its entirety.  A client releases an address
+   block by sending a Release message that includes an IA_LL option
+   containing the LLADDR option for the address block to release.  The
+   Release transmission mechanism is described in Section 18.2.7 of
+   [RFC8415].
+
+   Note that if the client is releasing the link-layer address it is
+   using, it MUST stop using this address before sending the Release
+   message (as per [RFC8415]).  In order to send the Release message,
+   the client MUST use another address (such as the one originally used
+   to initiate DHCPv6 to provide an allocated link-layer address).
+
+11.  Option Definitions
+
+   This mechanism uses an approach similar to the existing mechanisms in
+   DHCP.  There is one container option (the IA_LL option) that contains
+   the actual address or addresses, represented by an LLADDR option.
+   Each LLADDR option represents an address block, which is expressed as
+   a first address with a number that specifies how many additional
+   addresses are included.
+
+11.1.  Identity Association for Link-Layer Addresses Option
+
+   The Identity Association for Link-Layer Addresses option (the IA_LL
+   option) is used to carry an IA_LL, the parameters associated with the
+   IA_LL, and the address blocks associated with the IA_LL.
+
+   The format of the IA_LL option is:
+
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          OPTION_IA_LL         |          option-len           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                        IAID (4 octets)                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                          T1 (4 octets)                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                          T2 (4 octets)                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     .                                                               .
+     .                         IA_LL-options                         .
+     .                                                               .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 1: IA_LL Option Format
+
+   option-code     OPTION_IA_LL (138).
+
+   option-len      12 + length of IA_LL-options field.
+
+   IAID            The unique identifier for this IA_LL; the IAID must
+                   be unique among the identifiers for all of this
+                   client's IA_LLs.  The number space for IA_LL IAIDs is
+                   separate from the number space for other IA option
+                   types (i.e., IA_NA, IA_TA, and IA_PD).  A 4-octet
+                   field containing an unsigned integer.
+
+   T1              The time interval after which the client should
+                   contact the server from which the addresses in the
+                   IA_LL were obtained to extend the valid lifetime of
+                   the addresses assigned to the IA_LL; T1 is a time
+                   duration relative to the current time expressed in
+                   units of seconds.  A 4-octet field containing an
+                   unsigned integer.
+
+   T2              The time interval after which the client should
+                   contact any available server to extend the valid
+                   lifetime of the addresses assigned to the IA_LL; T2
+                   is a time duration relative to the current time
+                   expressed in units of seconds.  A 4-octet field
+                   containing an unsigned integer.
+
+   IA_LL-options   Options associated with this IA_LL.  A variable-
+                   length field (12 octets less than the value in the
+                   option-len field).
+
+   An IA_LL option may only appear in the options area of a DHCP
+   message.  A DHCP message may contain multiple IA_LL options (though
+   each must have a unique IAID).
+
+   The status of any operations involving this IA_LL is indicated in a
+   Status Code option (see Section 21.13 of [RFC8415]) in the IA_LL-
+   options field.
+
+   Note that an IA_LL has no explicit "lifetime" or "lease length" of
+   its own.  When the valid lifetimes of all of the addresses in an
+   IA_LL have expired, the IA_LL can be considered to be expired.  T1
+   and T2 are included to give servers explicit control over when a
+   client recontacts the server about a specific IA_LL.
+
+   In a message sent by a client to a server, the T1 and T2 fields MUST
+   be set to 0.  The server MUST ignore any values in these fields in
+   messages received from a client.
+
+   In a message sent by a server to a client, the client MUST use the
+   values in the T1 and T2 fields for the T1 and T2 times, unless those
+   values in those fields are 0.  The values in the T1 and T2 fields are
+   the number of seconds until T1 and T2.
+
+   As per Section 7.7 of [RFC8415], the value 0xffffffff is taken to
+   mean "infinity" and should be used carefully.
+
+   The server selects the T1 and T2 times to allow the client to extend
+   the lifetimes of any address block in the IA_LL before the lifetimes
+   expire, even if the server is unavailable for some short period of
+   time.  Recommended values for T1 and T2 are .5 and .8 times the
+   shortest valid lifetime of the address blocks in the IA that the
+   server is willing to extend, respectively.  If the "shortest" valid
+   lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values
+   are also 0xffffffff.  If the time at which the addresses in an IA_LL
+   are to be renewed is to be left to the discretion of the client, the
+   server sets T1 and T2 to 0.  The client MUST follow the rules defined
+   in Section 14.2 of [RFC8415].
+
+   If a client receives an IA_LL with T1 greater than T2, and both T1
+   and T2 are greater than 0, the client discards the IA_LL option and
+   processes the remainder of the message as though the server had not
+   included the invalid IA_LL option.
+
+   The IA_LL-options field typically contains one or more LLADDR options
+   (see Section 11.2).  If a client does not include an LLADDR option in
+   a Solicit or Request message, the server MUST treat this as a request
+   for a single address and that the client has no hint as to the
+   address it would like.
+
+11.2.  Link-Layer Addresses Option
+
+   The Link-Layer Addresses option is used to specify an address block
+   associated with an IA_LL.  The option must be encapsulated in the
+   IA_LL-options field of an IA_LL option.  The LLaddr-options field
+   encapsulates those options that are specific to this address block.
+
+   The format of the Link-Layer Addresses option is:
+
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          OPTION_LLADDR        |          option-len           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       link-layer-type         |        link-layer-len         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     .                                                               .
+     .                     link-layer-address                        .
+     .                                                               .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                      extra-addresses                          |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                      valid-lifetime                           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     .                                                               .
+     .                      LLaddr-options                           .
+     .                                                               .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 2: LLADDR Option Format
+
+   option-code          OPTION_LLADDR (139).
+
+   option-len           12 + link-layer-len field value + length of
+                        LLaddr-options field.  Assuming a link-layer-
+                        address length of 6 and no extra options, the
+                        option-len would be 18.
+
+   link-layer-type      The link-layer type MUST be a valid hardware
+                        type assigned by IANA, as described in
+                        [RFC5494], and registered in the "Hardware
+                        Types" registry at
+                        <https://www.iana.org/assignments/arp-
+                        parameters>.  A 2-octet field containing an
+                        unsigned integer.
+
+   link-layer-len       Specifies the length, in octets, of the link-
+                        layer-address field (typically 6 for a link-
+                        layer-type of 1 (Ethernet) and 6 (IEEE 802
+                        Networks)).  This is to accommodate link layers
+                        that may have variable-length addresses.  A
+                        2-octet field containing an unsigned integer.
+
+   link-layer-address   Specifies the address of the first link-layer
+                        address that is being requested or assigned
+                        depending on the message.  A client MAY send a
+                        special value to request any address.  For link-
+                        layer types 1 and 6, see Section 7 for details
+                        on this field.  A link-layer-len length octet
+                        field containing an address.
+
+   extra-addresses      Specifies the number of additional addresses
+                        that follow the address specified in link-layer-
+                        address.  For a single address, 0 is used.  For
+                        example, link-layer-address 02:04:06:08:0a and
+                        extra-addresses 3 designate a block of four
+                        addresses, starting from 02:04:06:08:0a and
+                        ending with 02:04:06:08:0d (inclusive).  A
+                        4-octet field containing an unsigned integer.
+
+   valid-lifetime       The valid lifetime for the address(es) in the
+                        option, expressed in units of seconds.  A
+                        4-octet field containing an unsigned integer.
+
+   LLaddr-options       Any encapsulated options that are specific to
+                        this particular address block.  Currently, there
+                        are no such options defined, but there may be in
+                        the future.
+
+   In a message sent by a client to a server, the valid lifetime field
+   MUST be set to 0.  The server MUST ignore any received value.
+
+   In a message sent by a server to a client, the client MUST use the
+   value in the valid lifetime field for the valid lifetime for the
+   address block.  The value in the valid lifetime field is the number
+   of seconds remaining in the lifetime.
+
+   As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is
+   taken to mean "infinity" and should be used carefully.
+
+   More than one LLADDR option can appear in an IA_LL option.
+
+12.  Selecting Link-Layer Addresses for Assignment 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
+   administrator and the requirements of that address space.
+
+   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
+   client's link.
+
+   For IEEE 802 MAC addresses (see [IEEEStd802] as amended by
+   [IEEEStd802c]):
+
+   1.  Server administrators SHOULD follow the IEEE 802 Specifications
+       with regard to the unicast address pools made available for
+       assignment (see Appendix A and [IEEEStd802c]) -- only address
+       space reserved for local use or with the authorization of the
+       assignee may be used.
+
+   2.  Servers MUST NOT allow administrators to configure address pools
+       that would cross the boundary of 2^(42) bits (for 48-bit MAC
+       addresses) to avoid issues with changes in the first octet of the
+       address and the special bits therein (see Appendix A).  Clients
+       MUST reject assignments where the assigned block would cross this
+       boundary (they MUST decline the allocation -- see Section 18.2.8
+       of [RFC8415]).
+
+   3.  A server MAY use options supplied by a relay agent or client to
+       select the quadrant (see Appendix A) from which addresses are to
+       be assigned.  This MAY include options like those specified in
+       [RFC8948].
+
+13.  IANA Considerations
+
+   IANA has assigned the OPTION_IA_LL (138) option code from the "Option
+   Codes" subregistry of the "Dynamic Host Configuration Protocol for
+   IPv6 (DHCPv6)" registry maintained at
+   <http://www.iana.org/assignments/dhcpv6-parameters>:
+
+   Value:        138
+   Description:  OPTION_IA_LL
+   Client ORO:   No
+   Singleton Option:  No
+   Reference:    RFC 8947
+
+   IANA has assigned the OPTION_LLADDR (139) option code from the
+   "Option Codes" subregistry of the "Dynamic Host Configuration
+   Protocol for IPv6 (DHCPv6)" registry maintained at
+   <http://www.iana.org/assignments/dhcpv6-parameters>:
+
+   Value:        139
+   Description:  OPTION_LLADDR
+   Client ORO:   No
+   Singleton Option:  No
+   Reference:    RFC 8947
+
+14.  Security Considerations
+
+   See Section 22 of [RFC8415] and Section 23 of [RFC7227] for the DHCP
+   security considerations.  See [RFC8200] for the IPv6 security
+   considerations.
+
+   As discussed in Section 22 of [RFC8415]:
+
+   |  DHCP lacks end-to-end encryption between clients and servers;
+   |  thus, hijacking, tampering, and eavesdropping attacks are all
+   |  possible as a result.
+
+   In some network environments, it is possible to secure them, as
+   discussed later in Section 22 of [RFC8415].
+
+   If not all parties on a link use this mechanism to obtain an address
+   from the space assigned to the DHCP server, there is the possibility
+   of the same link-layer address being used by more than one device.
+   Note that this issue would exist on these networks even if DHCP were
+   not used to obtain the address.
+
+   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.
+
+15.  Privacy Considerations
+
+   See Section 23 of [RFC8415] for the DHCP privacy considerations.
+
+   For a client requesting a link-layer address directly from a server,
+   as the address assigned to a client will likely be used by the client
+   to communicate on the link, the address will be exposed to those able
+   to listen in on this communication.  For those peers on the link that
+   are able to listen in on the DHCP exchange, they would also be able
+   to correlate the client's identity (based on the DUID used) with the
+   assigned address.  Additional mechanisms, such as the ones described
+   in [RFC7844], can also be used to improve anonymity by minimizing
+   what is exposed.
+
+   As discussed in Section 23 of [RFC8415], DHCP servers and hypervisors
+   may need to consider the implications of assigning addresses
+   sequentially.  Though in general, this is only of link-local concern
+   unlike for IPv6 address assignment and prefix delegation, as these
+   may be used for communication over the Internet.
+
+16.  References
+
+16.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              DOI 10.17487/RFC4861, September 2007,
+              <https://www.rfc-editor.org/info/rfc4861>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
+              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
+              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+              RFC 8415, DOI 10.17487/RFC8415, November 2018,
+              <https://www.rfc-editor.org/info/rfc8415>.
+
+16.2.  Informative References
+
+   [IEEE-P802.1CQ-Project]
+              IEEE, "P802.1CQ - Standard for Local and Metropolitan Area
+              Networks: Multicast and Local Address Assignment",
+              <https://standards.ieee.org/project/802_1CQ.html>.
+
+   [IEEEStd802]
+              IEEE, "IEEE Standard for Local and Metropolitan Area
+              Networks: Overview and Architecture, IEEE Std 802", IEEE
+              STD 802-2014, DOI 10.1109/IEEESTD.2014.6847097,
+              <https://doi.org/10.1109/IEEESTD.2014.6847097>.
+
+   [IEEEStd802.11]
+              IEEE, "IEEE Standard for Information technology--
+              Telecommunications and information exchange between
+              systems Local and metropolitan area networks--Specific
+              requirements - Part 11: Wireless LAN Medium Access Control
+              (MAC) and Physical Layer (PHY) Specifications", IEEE Std
+              802.11, DOI 10.1109/IEEESTD.2016.7786995,
+              <https://doi.org/10.1109/IEEESTD.2016.7786995>.
+
+   [IEEEStd802c]
+              IEEE, "IEEE Standard for Local and Metropolitan Area
+              Networks:Overview and Architecture--Amendment 2: Local
+              Medium Access Control (MAC) Address Usage", IEEE Std 802c-
+              2017, DOI 10.1109/IEEESTD.2017.8016709,
+              <https://doi.org/10.1109/IEEESTD.2017.8016709>.
+
+   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
+              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
+              <https://www.rfc-editor.org/info/rfc2464>.
+
+   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
+              for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
+              <https://www.rfc-editor.org/info/rfc4429>.
+
+   [RFC5494]  Arkko, J. and C. Pignataro, "IANA Allocation Guidelines
+              for the Address Resolution Protocol (ARP)", RFC 5494,
+              DOI 10.17487/RFC5494, April 2009,
+              <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
+              Profiles for DHCP Clients", RFC 7844,
+              DOI 10.17487/RFC7844, May 2016,
+              <https://www.rfc-editor.org/info/rfc7844>.
+
+   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", STD 86, RFC 8200,
+              DOI 10.17487/RFC8200, July 2017,
+              <https://www.rfc-editor.org/info/rfc8200>.
+
+   [RFC8948]  Bernardos, CJ. and A. Mourad, "Structured Local Address
+              Plan (SLAP) Quadrant Selection Option for DHCPv6",
+              RFC 8948, DOI 10.17487/RFC8948, December 2020,
+              <https://www.rfc-editor.org/info/rfc8948>.
+
+Appendix A.  IEEE 802c Summary
+
+   This appendix provides a brief summary of IEEE 802c [IEEEStd802c].
+
+   The original IEEE 802 specifications assigned half of the 48-bit MAC
+   address space to local use -- these addresses have the U/L bit set to
+   1 and are locally administered with no imposed structure.
+
+   In 2017, the IEEE issued the IEEE Std 802c specification, which
+   defines a new optional "Structured Local Address Plan (SLAP) that
+   specifies different assignment approaches in four specified regions
+   of the local MAC address space".  Under this plan, there are four
+   SLAP quadrants that use different assignment policies.
+
+   The first octet of the MAC address Z and Y bits define the quadrant
+   for locally assigned addresses (X-bit is 1).  In IEEE representation,
+   these bits are as follows:
+
+
+       LSB                MSB
+       M  X  Y  Z  -  -  -  -
+       |  |  |  |
+       |  |  |  +------------ SLAP Z-bit
+       |  |  +--------------- SLAP Y-bit
+       |  +------------------ X-bit (U/L) = 1 for locally assigned
+       +--------------------- M-bit (I/G) (unicast/group)
+
+                            Figure 3: SLAP Bits
+
+
+   The SLAP quadrants are:
+
+     +==========+=======+=======+=======================+============+
+     | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local      |
+     |          |       |       |                       | Identifier |
+     +==========+=======+=======+=======================+============+
+     |       01 | 0     | 1     | Extended Local        | ELI        |
+     +----------+-------+-------+-----------------------+------------+
+     |       11 | 1     | 1     | Standard Assigned     | SAI        |
+     +----------+-------+-------+-----------------------+------------+
+     |       00 | 0     | 0     | Administratively      | AAI        |
+     |          |       |       | Assigned              |            |
+     +----------+-------+-------+-----------------------+------------+
+     |       10 | 1     | 0     | Reserved              | Reserved   |
+     +----------+-------+-------+-----------------------+------------+
+
+                          Table 1: SLAP Quadrants
+
+   MAC addresses derived from an Extended Local Identifier (ELI) are
+   based on an assigned Company ID (CID), which is 24 bits (including
+   the M, X, Y, and Z bits) for 48-bit MAC addresses.  This leaves 24
+   bits for the locally assigned address for each CID for unicast (M-bit
+   = 0) and also for multicast (M-bit = 1).  The CID is assigned by the
+   IEEE Registration Authority (RA).
+
+   MAC addresses derived from a Standard Assigned Identifier (SAI) are
+   assigned by a protocol specified in an IEEE 802 standard.  For 48-bit
+   MAC addresses, 44 bits are available.  Multiple protocols for
+   assigning SAIs may be specified in IEEE standards.  Coexistence of
+   multiple protocols may be supported by limiting the subspace
+   available for assignment by each protocol.
+
+   MAC addresses derived from an Administratively Assigned Identifier
+   (AAI) are assigned locally.  Administrators manage the space as
+   needed.  Note that multicast IPv6 packets [RFC2464] use a destination
+   address starting in 33-33, so AAI addresses in that range should not
+   be assigned.  For 48-bit MAC addresses, 44 bits are available.
+
+   The last quadrant is reserved for future use.  While this quadrant
+   may also be used similar to AAI space, administrators should be aware
+   that future specifications may define alternate uses that could be
+   incompatible.
+
+Acknowledgments
+
+   Thanks to the DHC Working Group participants that reviewed this
+   document and provided comments and support.  With special thanks to
+   Ian Farrer for his thorough reviews and shepherding of this document
+   through the IETF process.  Thanks also to directorate reviewers
+   Samita Chakrabarti, Roni Even, and Tianran Zhou and IESG members
+   Martin Duke, Benjamin Kaduk, Murray Kucherawy, Warren Kumari, Barry
+   Leiba, Alvaro Retana, Éric Vyncke, and Robert Wilton for their
+   suggestions.  And thanks to Roger Marks, Robert Grow, and Antonio de
+   la Oliva for comments related to IEEE work and references.
+
+Authors' Addresses
+
+   Bernie Volz
+   Cisco Systems, Inc.
+   300 Beaver Brook Rd
+   Boxborough, MA 01719
+   United States of America
+
+   Email: volz@cisco.com
+
+
+   Tomek Mrugalski
+   Internet Systems Consortium, Inc.
+   PO Box 360
+   Newmarket, NH 03857
+   United States of America
+
+   Email: tomasz.mrugalski@gmail.com
+
+
+   Carlos J. Bernardos
+   Universidad Carlos III de Madrid
+   Av. Universidad, 30
+   28911 Leganes, Madrid
+   Spain
+
+   Phone: +34 91624 6236
+   Email: cjbc@it.uc3m.es
+   URI:   http://www.it.uc3m.es/cjbc/