<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="std" docName="draft-ietf-dhc-mac-assign-09">
     docName="draft-ietf-dhc-mac-assign-09" number="8947" updates=""
     obsoletes="" submissionType="IETF" consensus="true" xml:lang="en"
     tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.0.0 -->
  <front>
    <title abbrev="DHCPv6 Link-Layer Address Assignment">
    Link-Layer Addresses Assignment Mechanism for DHCPv6</title>
    <seriesInfo name="RFC" value="8947"/>
    <author fullname="Bernie Volz" initials="B" surname="Volz">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>1414 Massachusetts Ave</street>
          <city>Boxborough, MA 01719</city>
          <country>USA</country>
          <street>300 Beaver Brook Rd</street>
          <city>Boxborough</city>
	  <region>MA</region>
	  <code>01719</code>
          <country>United States of America</country>
        </postal>
        <email>volz@cisco.com</email>
      </address>
    </author>
    <author fullname="Tomek Mrugalski" initials="T." surname="Mrugalski">
      <organization abbrev="ISC">Internet Systems Consortium,
      Inc.</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <region>CA</region>
          <code>94063</code>
          <country>USA</country>
          <street>PO Box 360</street>
          <city>Newmarket</city>
          <region>NH</region>
          <code>03857</code>
          <country>United States of America</country>
        </postal>
        <email>tomasz.mrugalski@gmail.com</email>
      </address>
    </author>
    <author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos">
      <organization abbrev="UC3M">Universidad Carlos III de
      Madrid</organization>
      <address>
        <postal>
          <street>Av. Universidad, 30</street>
          <city>Leganes, Madrid</city>
          <code>28911</code>
          <country>Spain</country>
        </postal>
        <phone>+34 91624 6236</phone>
        <email>cjbc@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es/cjbc/</uri>
      </address>
    </author>
    <date month="November" year="2020"/>
    <area>Internet</area>
    <workgroup>Dynamic Host Configuration (DHC)</workgroup>
    <keyword>DHCPv6</keyword>
    <keyword>DHCP</keyword>
    <keyword>Link-layer</keyword>
    <keyword>assignment</keyword>

    <!--  SECTION 0:  Abstract                      -->
    <abstract>
      <t>In certain environments, e.g., large scale 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
      Therefore, an allocation mechanism is required. This draft 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.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction">
      <!-- 1, line 230--> anchor="intro">
      <name>Introduction</name>
      <t>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
      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 <xref target="RFC4429"/>). target="RFC4429" sectionFormat="of" section="A.1"/>). Another
      use case is IoT (Internet Internet of Things) Things (IoT) devices (see
      <xref target="RFC7228"/>). The huge number of such devices could
      strain the IEEE's available OUI (Organizationally Organizationally Unique Identifier) 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 MAC (media access control) Media Access Control (MAC) addresses.</t>
      <t>This document proposes a new mechanism that extends DHCPv6
      operation to handle link-layer address assignments.</t>

      <t>Since DHCPv6 (<xref target="RFC8415"/>) <xref target="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.</t>
      <t>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 <xref target="IEEEStd802"/>. Future
      documents may provide specifics for other link-layer address
      types.</t>
      <t>IEEE 802 originally set aside half of the 48-bit MAC address
      space for local use (where the U/L Universal/Local (U/L) bit is set to 1). In 2017,
      IEEE published an amendment <xref target="IEEEStd802c"/> that
      divides this space into quadrants with differentied differentiated address rules.
      More details are in <xref target="IEEE802cSummary"/>.</t>
      <t>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 <xref target="IEEE-P802.1CQ-Project"/>.</t>
    </section>
    <section anchor="requirements" title="Requirements">
      <t>The anchor="requirements">
      <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
      BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174" /> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section anchor="terminology" title="Terminology"> anchor="terminology">
      <name>Terminology</name>
      <t>The DHCP terminology relevant to this specification from
      <xref target="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.</t>

      <t>
        <list hangIndent="14" style="hanging">
          <t hangText="address">Unless
      <dl newline="false" spacing="normal" indent="16">
        <dt>address</dt>
        <dd>Unless specified otherwise, an address
          means a link-layer (or MAC) address, as specified in
          <xref target="IEEEStd802"/>. The
          address is typically six octets long, but some network
          architectures may use different lengths.</t>

          <t hangText="address block">A lengths.</dd>
        <dt>address block</dt>
        <dd>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.</t>

          <t hangText="client">A addresses.</dd>
        <dt>client</dt>
        <dd>A node that is interested in obtaining
          link-layer addresses. It implements the basic DHCP mechanisms
          needed by a DHCP
          client
          client, as described in <xref target="RFC8415"/> target="RFC8415"/>, and
          supports the new options (IA_LL and LLADDR, see below) specified in this document. document (IA_LL and LLADDR). The client may or may not support IPv6
          address assignment and prefix delegation delegation, as specified in
          <xref target="RFC8415"/>.</t>

          <t hangText="IA_LL">Identity target="RFC8415"/>.</dd>
        <dt>IA_LL</dt>
        <dd>Identity Association for Link-Layer Address: Address,
          an identity association (IA) used to request or assign
          link-layer addresses. See <xref target="IA_LL"/> for details on
          the IA_LL option.</t>

          <t hangText="LLADDR">Link-layer option.</dd>
        <dt>LLADDR</dt>
        <dd>Link-layer address option that is used to
          request or assign a block of link-layer addresses. See
          <xref target="LLADDR"/> for details on the LLADDR option.</t>

          <t hangText="server">A option.</dd>
        <dt>server</dt>
        <dd>A node that manages link-layer address allocation
          and is able to respond to client queries. It implements basic DHCP
          server functionality functionality, as described in <xref target="RFC8415"/> target="RFC8415"/>, and
          supports the new options
          (IA_LL and LLADDR) specified in this document. document
          (IA_LL and LLADDR). The server may or
          may not support IPv6 address assignment and prefix delegation as
          specified in <xref target="RFC8415"/>.</t>

        </list>
      </t> target="RFC8415"/>.</dd>
      </dl>
    </section>
    <section anchor="overview" title="Deployment scenarios and mechanism overview"> anchor="overview">
      <name>Deployment Scenarios</name>
      <t>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, mode and (ii) direct client mode.</t>
      <section anchor="proxy" title="Proxy client mode scenario"> anchor="proxy">
        <name>Scenario: Proxy Client Mode</name>

        <t>This mode is used when an entity acts as a DHCP client and that
	requests that available DHCP servers to assign one or more
        addresses (an address block), block) for the DHCP client to be then assigned for use by
	assign to the final end-devices. end devices to use. Large-scale virtualization is one
        application scenario for proxy client mode. In such
        environments
        environments, this entity is often called a hypervisor "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 usage.
        use. Some obsolete VMs will be deleted and deleted; their addresses
        are potentially eligible for reuse for by new VMs.</t>
      </section>
      <section anchor="direct" title="Direct client mode scenario"> anchor="direct">
        <name>Scenario: Direct Client Mode</name>
        <t>This mode can be used when an entity acts as a DHCP client and that
        requests that available DHCP servers to assign one or more addresses
        (an address block) for its own use. This usage scenario is related to
        IoT, as described earlier
        IoT (see <xref target="intro"/>). Upon first
        boot, for each interface interface, the device uses a temporary address, as
        described in <xref target="IEEEStd802.11"/> or to be described in and
        IEEE 802.1CQ <xref target="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.</t>
        <t>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 <bcp14>MUST
        NOT</bcp14> use a link-layer based DUID (DHCP link-layer-based DHCP Unique Identifier). Identifier (DUID). For more
        details, refer to Section 11 of <xref target="RFC8415"/>.</t> target="RFC8415" sectionFormat="of"
	section="11"/>.</t>
        <t>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, used
        or may require the administrator to adjust the configuration of
        the switch(es) to allow a change in address.</t>
      </section>
    </section>
      <section anchor="mechanism" title="Mechanism Overview"> anchor="mechanism">
        <name>Mechanism Overview</name>

        <t>In all the scenarios described in <xref target="overview"/>, the protocol operates in fundamentally the
        same way.

	The device requesting an address, acting as a DHCP
        client, will send a Solicit message with a an IA_LL option to all
        available DHCP servers. That IA_LL option MUST <bcp14>MUST</bcp14> include a an LLADDR
        option specifying the link-layer-type and
        link-layer-len
        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 response, as
        governed by <xref target="RFC8415"/>. If necessary, the client
        sends a Request message and 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).</t>
        <t>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 <xref target="RFC8415"/>). target="RFC8415"
	sectionFormat="of" section="7.7"/>). An administrator may make the
	address assignment permanent by specifying use of the "infinity" valid
        lifetime, as defined in Section 7.7 of <xref target="RFC8415"/>.</t> target="RFC8415" sectionFormat="of"
	section="7.7"/>.</t>
        <t>The client can release addresses when they are no longer
        needed by sending a Release message (see Section 18.2.7
        of <xref target="RFC8415"/>).</t> target="RFC8415"
	sectionFormat="of" section="18.2.7"/>).</t>
        <t>Figure 9 in <xref target="RFC8415"/> shows
        a timeline diagram of the messages exchanged between a client and
        two servers for the typical lifecycle life cycle of one or more leases.</t>
        <t>Confirm and Information-Request Information-request messages are not used in
        link-layer address assignment. Decline should technically
        never be needed, but see <xref target="selecting-addresses"/> for
        one situation where this message is needed.</t>
        <t>Clients implementing this mechanism SHOULD <bcp14>SHOULD</bcp14> use the Rapid Commit
        option
        option, as specified in Section 5.1 Sections <xref target="RFC8415" section="5.1"
	sectionFormat="bare"/> and 18.2.1 <xref target="RFC8415" section="18.2.1"
	sectionFormat="bare"/> of <xref target="RFC8415"/> target="RFC8415"/>, to obtain addresses
	with a 2-message two-message exchange when possible.</t>
        <t>Devices supporting this proposal MAY <bcp14>MAY</bcp14> support the reconfigure
        mechanism, as defined in Section 18.2.11 of <xref target="RFC8415"/>. target="RFC8415" sectionFormat="of"
	section="18.2.11"/>. 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
        Reconfigure
        Reconfiguration Key Authentication Protocol (See Section 20.4 of (see <xref target="RFC8415"/>), target="RFC8415"
	sectionFormat="of" section="20.4"/>), small-footprint devices may
	choose to not to support it.</t>
      </section>

    </section>

    <section title="Design Assumptions">

    <section>
      <name>Design Assumptions</name>
      <t>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 time, the number of addresses requested
      by the hypervisor(s) will increase as more VMs are spawned.</t>
      <t>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
      Therefore, the mechanism should operate on address blocks, blocks rather
      than single values. A single address can be treated as an address
      block with just one address.</t>
      <t>The DHCP mechanisms are reused to a large degree, including message
      and option formats, transmission mechanisms, relay infrastructure 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,
      addresses but not IPv6 addresses or prefixes.</t>
    </section>
    <section anchor="Information-Encoding" title="Information Encoding"> anchor="Information-Encoding">
      <name>Information Encoding</name>
      <t>A client MUST <bcp14>MUST</bcp14> send a 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:

      <list hangIndent="4" style="hanging">
        <t hangText="1.">All
      </t>
      <ol spacing="normal" type="1">
        <li>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).
        </t>

        <t hangText="2.">Any
	</li>
        <li>Any other value to request a specific block of
        address starting with the specified address<!-- (this may be a
          unicast or multicast address).-->
        </t>
      </list>
      </t> address.
        </li>
      </ol>
      <t>Encoding information for other link-layer-types may be added in
      the future by publishing an RFC that specifies those values.</t>
      <t>A client sets the extra-addresses field to either 0 for a single
      address or the size of the requested address block minus 1.</t>
      <t>A client MUST <bcp14>MUST</bcp14> set the valid-lifetime field to 0 (this field
      MUST
      <bcp14>MUST</bcp14> be ignored by the server).</t>
    </section>

    <section title="Requesting Addresses">
    <section>
      <name>Requesting Addresses</name>
      <t>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 in the message. inside. The IA_LL option MUST <bcp14>MUST</bcp14>
      contain a an LLADDR option option, as specified in
      <xref target="Information-Encoding"/>.</t>
      <t>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 <bcp14>MAY</bcp14> take into consideration the
      address block requested by the client in the LLADDR option. However,
      the server MAY <bcp14>MAY</bcp14> choose to ignore some or all parameters of the
      requested address block. In particular, the server may send
      either a
      different starting address than requested, 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 addresses, it MUST <bcp14>MUST</bcp14> return the IA_LL option containing a
      Status Code option (see Section 21.13 of <xref target="RFC8415"/>) target="RFC8415" sectionFormat="of"
      section="21.13"/>) with status set to NoAddrsAvail.</t>

      <t>Note: Servers
      <t>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 <bcp14>MUST</bcp14> treat this as if the server
      returned the NoAddrsAvail status for these IA_LL option(s).
      </t>
      <t>The client waits for available servers to send Advertise
      responses and picks one server server, as defined in Section 18.2.9 of <xref target="RFC8415"/>. target="RFC8415"
      sectionFormat="of" section="18.2.9"/>. 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.</t>

      <t>The client MUST <bcp14>MUST</bcp14> process the address block(s) returned in the
      Advertise, rather than what it included in the Solicit, 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 <bcp14>MUST NOT</bcp14> 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.</t>
      <t>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
      <bcp14>MAY</bcp14> 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.</t>
      <t>Upon receiving a Reply message, the client parses the IA_LL
      container option and may start using all provided addresses. It MUST <bcp14>MUST</bcp14>
      restart its T1 and T2 timers using the values specified in the IA_LL
      option.</t>
      <t>The client MUST <bcp14>MUST</bcp14> use the address block(s) returned in the Reply
      message, which may be a smaller block(s) or with may have a different address(es)
      than requested.</t>
      <t>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 <xref target="RFC8415"/>).</t> target="RFC8415"
      sectionFormat="of" section="18.2.1"/>).</t>
      <t>A client that changes its link-layer address on an interface
      SHOULD
      <bcp14>SHOULD</bcp14> follow the recommendations in Section 7.2.6 of <xref target="RFC4861"/>
      target="RFC4861" sectionFormat="of" section="7.2.6"/> to inform its
      neighbors of the new link-layer address quickly.</t>
    </section>

    <section title="Renewing Addresses">
    <section>
      <name>Renewing Addresses</name>
      <t>Address renewals follow the normal DHCP renewals processing
      described in Section 18.2.4 of <xref target="RFC8415"/>. target="RFC8415" sectionFormat="of"
      section="18.2.4"/>. Once the T1
      timer elapses, the client starts sending Renew messages with the
      IA_LL option containing a 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 <bcp14>MUST NOT</bcp14> 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 <bcp14>MUST NOT</bcp14>
      change.</t>
      <t>If the requesting client needs additional addresses -- e.g., (e.g., in
      the hypervisor scenario because addresses need to be assigned to new
      VMs --
      VMs), it MUST <bcp14>MUST</bcp14> send an IA_LL option with a different IAID
      Identity Association IDentifier (IAID) to create
      another "container" for more addresses.</t>
      <t>If the client is unable to Renew renew before the T2 timer elapses, it
      starts sending Rebind messages messages, as described in Section 18.2.5 of
      <xref target="RFC8415"/>.</t> target="RFC8415" sectionFormat="of" section="18.2.5"/>.</t>
    </section>

    <section title="Releasing Addresses">
    <section>
      <name>Releasing Addresses</name>
      <t>The client may decide to release a leased address block. A client
      MUST
      <bcp14>MUST</bcp14> release the whole 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 <xref target="RFC8415"/>.</t>

      <t>Note: If
      target="RFC8415" sectionFormat="of" section="18.2.7"/>.</t>
      <t>Note that if the client is releasing the link-layer address it is
      using, it MUST <bcp14>MUST</bcp14> stop using this address before sending the
      Release message (as per <xref target="RFC8415"/>). In order to send
      the Release message, the client MUST <bcp14>MUST</bcp14> use another address (such as
      the one originally used to initiate DHCPv6 to provide an allocated
      link-layer address).</t>
    </section>
    <section anchor="option" title="Option Definitions"> anchor="option">
      <name>Option Definitions</name>
      <t>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.</t>
      <section anchor="IA_LL"
               title="Identity anchor="IA_LL">
        <name>Identity Association for Link-Layer Addresses Option"> Option</name>
        <t>The Identity Association for Link-Layer Addresses option (IA_LL
	(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.</t>
        <t>The format of the IA_LL option is:</t>
        <figure align="center" anchor="ia-ll-syntax"
              title="IA_LL anchor="ia-ll-syntax">
          <name>IA_LL Option Format"> Format</name>
          <artwork align="left"><![CDATA[
   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                         .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>
          <list hangIndent="16" style="hanging">
            <t hangText="option-code">OPTION_IA_LL (tbd1).</t>

            <t hangText="option-len">12
        <dl newline="false" spacing="normal" indent="16">
          <dt>option-code</dt>
          <dd>OPTION_IA_LL (138).</dd>
          <dt>option-len</dt>
          <dd>12 + length of IA_LL-options field.</t>

            <t hangText="IAID">The field.</dd>
          <dt>IAID</dt>
          <dd>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.</t>

            <t hangText="T1">The integer.</dd>
          <dt>T1</dt>
          <dd>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.
                           </t>

            <t hangText="T2">The
                           </dd>
          <dt>T2</dt>
          <dd>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.
                           </t>

            <t hangText="IA_LL-options">Options
                           </dd>
          <dt>IA_LL-options</dt>
          <dd>Options associated with this
                           IA_LL. A variable length variable-length field (12 octets less
                           than the value in the option-len field).</t>
          </list>
        </t> field).</dd>
        </dl>
        <t>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).</t>
        <t>The status of any operations involving this IA_LL is indicated
        in a Status Code option (see Section 21.13 of <xref target="RFC8415"/>) target="RFC8415" sectionFormat="of"
	section="21.13"/>) in the IA_LL-options field.
        </t> field.</t>
        <t>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 as having 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.</t>
        <t>In a message sent by a client to a server, the T1 and T2 fields
        MUST
        <bcp14>MUST</bcp14> be set to 0.  The server MUST <bcp14>MUST</bcp14> ignore any values in these
        fields in messages received from a client.</t>
        <t>In a message sent by a server to a client, the client MUST <bcp14>MUST</bcp14> 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.</t>
        <t>As per Section 7.7 of <xref target="RFC8415"/>), target="RFC8415" sectionFormat="of" section="7.7"/>,
        the value 0xffffffff is taken to mean "infinity" and should be
        used carefully.</t>
        <t>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 <bcp14>MUST</bcp14> follow the rules defined in Section 14.2 in
        <xref target="RFC8415"/>. target="RFC8415" sectionFormat="of" section="14.2"/>.
        </t>
        <t>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.</t>
        <t>The IA_LL-options field typically contains one or more LLADDR
        options (see <xref target="LLADDR"/>). If a client does not include
        a
        an LLADDR option in a Solicit or Request message, the server MUST <bcp14>MUST</bcp14>
        treat this as a request for a single address and that the
        client has no hint as to the address it would like.</t>
      </section>
      <section anchor="LLADDR" title="Link-Layer anchor="LLADDR">
        <name>Link-Layer Addresses Option"> Option</name>
        <t>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 fields field
   encapsulates those options that are specific to this address block.</t>
        <t>The format of the Link-Layer Addresses option is:</t>
        <figure align="center" anchor="lladdr-syntax"
                title="LLADDR anchor="lladdr-syntax">
          <name>LLADDR Option Format"> Format</name>
          <artwork align="left"><![CDATA[
   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                           .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>
          <list hangIndent="16" style="hanging">
            <t hangText="option-code">OPTION_LLADDR (tbd2).</t>

            <t hangText="option-len">12
        <dl newline="false" spacing="normal" indent="21">
          <dt>option-code</dt>
          <dd>OPTION_LLADDR (139).</dd>
          <dt>option-len</dt>
          <dd>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.</t>

            <t hangText="link-layer-type">The 18.</dd>
            <dt>link-layer-type</dt>

          <dd>The link-layer type MUST <bcp14>MUST</bcp14> be a
            valid hardware type assigned by the IANA, as described in
            <xref target="RFC5494"/> target="RFC5494"/>, and registered in the "Hardware Types" table registry at
            https://www.iana.org/assignments/arp-parameters.
            <eref target="https://www.iana.org/assignments/arp-parameters" brackets="angle"/>.
            A 2-octet field containing an unsigned integer.</t>

            <t hangText="link-layer-len">Specifies integer.</dd>
          <dt>link-layer-len</dt>
          <dd>Specifies the length, in octets,
            of the link-layer-address field (typically 6, 6 for a
            link-layer-type of 1 (Ethernet) and 6 (IEEE 802 Networks)).
            This is to accommodate link-layers link layers that may have
            variable-length addresses. A 2-octet field containing an
            unsigned integer.</t>

            <t hangText="link-layer-address">Specifies integer.</dd>
          <dt>link-layer-address</dt>
          <dd>Specifies the address of
            the first link-layer address that is being requested or
            assigned depending on the message. A client MAY <bcp14>MAY</bcp14> send a
            special value to request any address.

	    For a link-layer
            type of
            types 1 and 6, see
            <xref target="Information-Encoding"/> for details on this
            field. A link-layer-len length octet field containing an
            address.</t>

            <t hangText="extra-addresses">Specifies
            address.</dd>
          <dt>extra-addresses</dt>
          <dd>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: example, link-layer-address 02:04:06:08:0a and
            extra-addresses 3 designates designate a block of 4 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.</t>

            <t hangText="valid-lifetime">The integer.</dd>
          <dt>valid-lifetime</dt>
          <dd>The valid lifetime for the
            address(es) in the option, expressed in units of seconds.
            A 4-octet field containing an unsigned integer.</t>

            <t hangText="LLaddr-options">Any integer.</dd>
          <dt>LLaddr-options</dt>
          <dd>Any encapsulated options that
            are specific to this particular address block. Currently Currently, there
            are no such options defined, but there may be in the future.
            </t>
          </list>
        </t>
            </dd>
        </dl>
        <t>In a message sent by a client to a server, the valid
        lifetime field MUST <bcp14>MUST</bcp14> be set to 0.  The server MUST <bcp14>MUST</bcp14> ignore any
        received value.</t>
        <t>In a message sent by a server to a client, the client MUST <bcp14>MUST</bcp14> 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.</t>
        <t>As per Section 7.7 of <xref target="RFC8415"/>, target="RFC8415" sectionFormat="of" section="7.7"/>,
        the valid lifetime of 0xffffffff is taken to mean "infinity" and
        should be used carefully.</t>
        <t>More than one LLADDR option can appear in an IA_LL option.</t>
      </section>
    </section>
    <section anchor="selecting-addresses"
             title="Selecting anchor="selecting-addresses">
      <name>Selecting Link-Layer Addresses for Assignment to an IA_LL"> IA_LL</name>
      <t>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.</t>
      <t>Link-layer addresses are typically specific to a link and the
      server SHOULD <bcp14>SHOULD</bcp14> follow the steps in Section 13.1 of <xref target="RFC8415"/> target="RFC8415"
      sectionFormat="of" section="13.1"/> to determine the client's link.</t>
      <t>For IEEE 802 MAC addresses (see <xref target="IEEEStd802"/> as
      amended by <xref target="IEEEStd802c"/>):
      <list hangIndent="4" style="hanging">
        <t hangText="1.">Server target="IEEEStd802c"/>):</t>
      <ol spacing="normal" type="1">
        <li>Server administrators SHOULD <bcp14>SHOULD</bcp14> follow the IEEE 802
        Specifications with regards regard to the unicast address pools made
        available for assignment (see <xref target="IEEE802cSummary"/> and
        <xref target="IEEEStd802c"/>) -- only address space reserved for
        local use or with the authorization of the assignee may be used.
        </t>

        <t hangText="2.">Servers MUST NOT
        </li>
        <li>Servers <bcp14>MUST NOT</bcp14> allow administrators to
        configure address pools that would cross the 2^42 bit boundary of 2<sup>42</sup> bits
        (for 48-bit MAC addresses) to avoid issues with changes in the
        first octet of the address and the special bits therein (see
        <xref target="IEEE802cSummary"/>). Clients MUST <bcp14>MUST</bcp14> reject assignments
        where the assigned block would cross this boundary (they MUST <bcp14>MUST</bcp14>
        decline the allocation - -- see Section 18.2.8 of <xref target="RFC8415"/>).
        </t>

        <t hangText="3.">A target="RFC8415" sectionFormat="of"
	section="18.2.8"/>).
        </li>
        <li>A server MAY <bcp14>MAY</bcp14> use options supplied by a
        relay agent or client to select the quadrant (see
        <xref target="IEEE802cSummary"/>) from which addresses are to be
        assigned. This MAY <bcp14>MAY</bcp14> include options, such as options like those specified in
        <xref target="I-D.ietf-dhc-slap-quadrant"/>.</t>
      </list>
      </t> target="RFC8948" format="default"/>.</li>
      </ol>
    </section>
    <section anchor="iana" title="IANA Considerations"> anchor="iana">
      <name>IANA Considerations</name>
      <t>IANA is requested to assign has assigned the OPTION_IA_LL (tbd1) (138)
   option code from the DHCPv6 "Option Codes" subregistry of the
   "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained at
   http://www.iana.org/assignments/dhcpv6-parameters and use the
   following data when adding the option to the registry:</t>

<figure>
<artwork align="left">
<![CDATA[
    Value:             tbd1
    Description:       OPTION_IA_LL
    Client ORO:        No
    Singleton Option:  No
    Reference:         this document
]]>
</artwork>
</figure>
   <eref target="http://www.iana.org/assignments/dhcpv6-parameters" brackets="angle"/>:</t>
<dl newline="false" spacing="compact" indent="14">
  <dt>Value:</dt>
  <dd>138</dd>
  <dt>Description:</dt>
  <dd>OPTION_IA_LL</dd>
  <dt>Client ORO:</dt>
  <dd>No</dd>
  <dt>Singleton Option:</dt>
  <dd>No</dd>
  <dt>Reference:</dt>
  <dd>RFC 8947</dd>
</dl>
      <t>IANA is requested to assign has assigned the OPTION_LLADDR (tbd2) (139)
      option code from the DHCPv6 "Option Codes" subregistry of the
   "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained at
   http://www.iana.org/assignments/dhcpv6-parameters and use the
   following data when adding the option to the registry:</t>

<figure>
<artwork align="left">
<![CDATA[
    Value:             tbd2
    Description:       OPTION_LLADDR
    Client ORO:        No
    Singleton Option:  No
    Reference:         this document
]]>
</artwork>
</figure>
   <eref target="http://www.iana.org/assignments/dhcpv6-parameters" brackets="angle"/>:</t>
<dl newline="false" spacing="compact" indent="14">
    <dt>Value:</dt>
    <dd>139</dd>
    <dt>Description:</dt>
    <dd>OPTION_LLADDR</dd>
    <dt>Client ORO:</dt>
    <dd>No</dd>
    <dt>Singleton Option:</dt>
    <dd>No</dd>
    <dt>Reference:</dt>
    <dd>RFC 8947</dd>
</dl>
    </section>
    <section anchor="security" title="Security Considerations"> anchor="security">
      <name>Security Considerations</name>
      <t>See Section 22 of <xref target="RFC8415"/> target="RFC8415" sectionFormat="of" section="22"/> and Section 23 of
      <xref target="RFC7227"/> target="RFC7227" sectionFormat="of" section="23"/> for
      the DHCP security considerations. See <xref target="RFC8200"/>
      for the IPv6 security considerations.</t>
      <t>As discussed in Section 22 of <xref target="RFC8415"/>, "DHCP target="RFC8415" sectionFormat="of" section="22"/>:</t> <blockquote><t>DHCP
      lacks end-to-end encryption between clients and servers; thus,
      hijacking, tampering, and eavesdropping attacks are all possible as
      a result." In result.</t></blockquote> <t>In some network environments, it is possible to secure
      them
      them, as discussed later in that Section 22.</t>

      <t>There is a possibility of the same link-layer address being
      used by more than one device if <xref target="RFC8415"
      sectionFormat="of" section="22"/>.</t>
      <t>If not all parties on a link use this mechanism to obtain an address from the space assigned to the DHCP server. 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.</t>
      <t>Server implementations SHOULD <bcp14>SHOULD</bcp14> 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.</t>
    </section>
    <section anchor="privacy" title="Privacy Considerations"> anchor="privacy">
      <name>Privacy Considerations</name>
      <t>See Section 23 of <xref target="RFC8415"/> target="RFC8415" sectionFormat="of" section="23"/> for the
      DHCP privacy considerations.</t>
      <t>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 <xref target="RFC7844"/> target="RFC7844"/>, can also be used to improve
      anonymity by minimizing what is exposed.</t>
      <t>As discussed in Section 23 of <xref target="RFC8415"/>, target="RFC8415" sectionFormat="of" section="23"/>, 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 delegation, as these may be used for communication over the
      Internet.</t>
    </section>

    <section title="Acknowledgements">

      <t>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. Thanks also to area reviewers
      Samita Chakrabarti, Roni Even and Tianran Zhou, and IESG members
      Martin Duke, Benjamin Kaduk, Murray Kucherawy, Warren Kumari, Barry
      Leiba, Alvaro Retana, Eric Vyncke, and Robert Wilton for their
      suggestions. And to Roger Marks, Bob Grow, and Antonio de la Oliva
      for comments related to IEEE work and references.
      </t>

    </section>
  </middle>
  <back>
    <references title="Normative References">

      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.4861'?>
      <?rfc include='reference.RFC.8174'?>
      <?rfc include="reference.RFC.8415'?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
      </references>

    <references title="Informative References">

      <?rfc include='reference.RFC.2464'?>
      <?rfc include='reference.RFC.4429'?>
      <?rfc include='reference.RFC.5494'?>
      <?rfc include='reference.RFC.7227'?>
      <?rfc include='reference.RFC.7228'?>
      <?rfc include='reference.RFC.7844'?>
      <?rfc include='reference.RFC.8200'?>

      <?rfc include='reference.I-D.ietf-dhc-slap-quadrant'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2464.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4429.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5494.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7227.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7844.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
	<reference anchor="RFC8948" target="https://www.rfc-editor.org/info/rfc8948">
<front>
<title>Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6</title>
<author initials='CJ' surname='Bernardos' fullname='Carlos J. Bernardos'>
  <organization>Universidad Carlos III de Madrid</organization>
</author>
<author initials='A' surname='Mourad' fullname='Alain Mourad'>
  <organization>InterDigital Europe</organization>
</author>
<date month='November' year='2020'/>
</front>
<seriesInfo name="RFC" value="8948"/>
<seriesInfo name="DOI" value="10.17487/RFC8948"/>
</reference>

        <reference anchor="IEEEStd802">
          <front>
          <title>
              IEEE
            <title>IEEE Standard for Local and Metropolitan Area Networks: Overview
	    and Architecture, IEEE Std 802
          </title>
          <author />
          <date /> 802</title>
            <author>
	      <organization>IEEE</organization>
	    </author>
          </front>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
	  <refcontent>IEEE STD 802-2014</refcontent>
        </reference>
        <reference anchor="IEEEStd802.11">
          <front>
            <title>
              IEEE Standard for Information technology - Telecommunications technology--Telecommunications
	      and information exchange between systems Local and metropolitan
	      area networks - Specific networks--Specific requirements - Part 11: Wireless LAN
	      Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std 802.11
	      Specifications
            </title>
          <author />
          <date />
            <author>
	      <organization>IEEE</organization>
	    </author>
          </front>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7786995"/>
	  <refcontent>IEEE Std 802.11</refcontent>
        </reference>
        <reference anchor="IEEEStd802c">
          <front>
            <title>
              IEEE Standard for Local and Metropolitan Area Networks: Overview Networks:Overview
	      and Architecture, Amendment Architecture--Amendment 2: Local Medium Access Control (MAC)
	      Address Usage, IEEE Std 802c-2017 Usage
            </title>
          <author />
          <date />
            <author>
	      <organization>IEEE</organization>
	    </author>
          </front>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8016709"/>
	  <refcontent>IEEE Std 802c-2017</refcontent>
        </reference>
        <reference anchor="IEEE-P802.1CQ-Project"
		   target="https://standards.ieee.org/project/802_1CQ.html">
          <front>
            <title>
            P802.1CQ - Standard for Local and Metropolitan Area Networks:
	    Multicast and Local Address Assignment
          </title>
          <author />
          <date /> Assignment</title>
            <author>
	      <organization>IEEE</organization>
	    </author>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="IEEE802cSummary" title="IEEE anchor="IEEE802cSummary">
      <name>IEEE 802c Summary"> Summary</name>
      <t>This appendix provides a brief summary of IEEE 802c
           <xref target="IEEEStd802c"/>.</t>
      <t>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.</t>
      <t>In 2017, the IEEE issued the IEEE Std 802c specification 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." space". Under this plan, there are 4 four SLAP
      quadrants that use different assignment policies.</t>
      <t>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:</t>
      <t keepWithNext="true"/>
      <figure align="center" anchor="SLAP-Bits"
                title="SLAP Bits">
          <preamble></preamble> anchor="SLAP-Bits">
        <name>SLAP Bits</name>
        <artwork align="left"><![CDATA[
    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)
]]></artwork>

          <postamble></postamble>
      </figure>
      <t keepWithPrevious="true"/>
      <t>The SLAP quadrants are:</t>

<texttable title="SLAP Quadrants">
<ttcol align='right'>Quadrant</ttcol>
<ttcol align='left'>Y-bit</ttcol>
<ttcol align='left'>Z-bit</ttcol>
<ttcol align='left'>Local
      <table>
        <name>SLAP Quadrants</name>
        <thead>
          <tr>
            <th align="right">Quadrant</th>
            <th align="left">Y-bit</th>
            <th align="left">Z-bit</th>
            <th align="left">Local Identifier Type</ttcol>
<ttcol align='left'>Local Identifier</ttcol>
     <c>01</c><c>0</c><c>1</c><c>Extended Local</c><c>ELI</c>
     <c>11</c><c>1</c><c>1</c><c>Standard Assigned</c><c>SAI</c>
     <c>00</c><c>0</c><c>0</c><c>Administratively Assigned</c><c>AAI</c>
     <c>10</c><c>1</c><c>0</c><c>Reserved</c><c>Reserved</c>
</texttable>

      <t>Extended Type</th>
            <th align="left">Local Identifier</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="right">01</td>
            <td align="left">0</td>
            <td align="left">1</td>
            <td align="left">Extended Local</td>
            <td align="left">ELI</td>
          </tr>
          <tr>
            <td align="right">11</td>
            <td align="left">1</td>
            <td align="left">1</td>
            <td align="left">Standard Assigned</td>
            <td align="left">SAI</td>
          </tr>
          <tr>
            <td align="right">00</td>
            <td align="left">0</td>
            <td align="left">0</td>
            <td align="left">Administratively Assigned</td>
            <td align="left">AAI</td>
          </tr>
          <tr>
            <td align="right">10</td>
            <td align="left">1</td>
            <td align="left">0</td>
            <td align="left">Reserved</td>
            <td align="left">Reserved</td>
          </tr>
        </tbody>
      </table>
      <t>MAC addresses derived from an Extended Local Identifier (ELI) derived MAC addresses are based
      on an assigned Company ID (CID), which is 24-bits 24 bits (including the M,
      X, Y, and Z bits) for 48-bit MAC addresses. This leaves 24-bits 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
      RA.</t>

      <t>Standard
      Registration Authority (RA).</t>
      <t>MAC addresses derived from a Standard Assigned Identifier (SAI) derived MAC addresses 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.</t>

      <t>Administratively
      <t>MAC addresses derived from an Administratively Assigned Identifier (AAI) derived MAC addresses
      are assigned locally. Administrators manage the space as needed.
      Note that multicast IPv6 packets (<xref target="RFC2464"/>) <xref target="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.</t>
      <t>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.</t>
    </section>
    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgments</name>
      <t>Thanks to the DHC Working Group participants that reviewed this
      document and provided comments and support. With special thanks to
      <contact fullname="Ian Farrer"/> for his thorough reviews and shepherding of this
      document through the IETF process. Thanks also to directorate reviewers
      <contact fullname="Samita Chakrabarti"/>, <contact fullname="Roni
      Even"/>, and <contact fullname="Tianran Zhou"/> and IESG members
      <contact fullname="Martin Duke"/>, <contact fullname="Benjamin Kaduk"/>,
      <contact fullname="Murray Kucherawy"/>, <contact fullname="Warren
      Kumari"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Alvaro
      Retana"/>, <contact fullname="Éric Vyncke"/>, and <contact
      fullname="Robert Wilton"/> for their
      suggestions. And thanks to <contact fullname="Roger Marks"/>, <contact
      fullname="Robert Grow"/>, and <contact fullname="Antonio de la
      Oliva"/>
      for comments related to IEEE work and references.
      </t>
    </section>
  </back>
</rfc>