<?xmlversion="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 scalelarge-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.ThereforeTherefore, an allocation mechanism is required. Thisdraftdocument 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> <sectionanchor="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.TypicallyTypically, the new VM instances are assigned a link-layer address, but random assignment does not scale well due to the risk of a collision (seeAppendix A.1 of<xreftarget="RFC4429"/>).target="RFC4429" sectionFormat="of" section="A.1"/>). Another use case isIoT (InternetInternet ofThings)Things (IoT) devices (see <xref target="RFC7228"/>). The huge number of such devices could strain the IEEE's availableOUI (OrganizationallyOrganizationally UniqueIdentifier)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 uniqueMAC (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 theU/LUniversal/Local (U/L) bit is set to 1). In 2017, IEEE published an amendment <xref target="IEEEStd802c"/> that divides this space into quadrants withdifferentieddifferentiated 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> <sectionanchor="requirements" title="Requirements"> <t>Theanchor="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 inBCP 14BCP 14 <xref target="RFC2119"/> <xreftarget="RFC8174" />target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <sectionanchor="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 meansa link-layer (or MAC) address, as specified in <xref target="IEEEStd802"/>. The address is typically six octets long, but some network architectures may use differentlengths.</t> <t hangText="address block">Alengths.</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 extraaddresses.</t> <t hangText="client">Aaddresses.</dd> <dt>client</dt> <dd>A node that is interested in obtaining link-layer addresses. It implements the basic DHCP mechanisms needed by a DHCPclientclient, as described in <xreftarget="RFC8415"/>target="RFC8415"/>, and supports the new options(IA_LL and LLADDR, see below)specified in thisdocument.document (IA_LL and LLADDR). The client may or may not support IPv6 address assignment and prefixdelegationdelegation, as specified in <xreftarget="RFC8415"/>.</t> <t hangText="IA_LL">Identitytarget="RFC8415"/>.</dd> <dt>IA_LL</dt> <dd>Identity Association for Link-LayerAddress:Address, an identity association (IA) used to request or assign link-layer addresses. See <xref target="IA_LL"/> for details on the IA_LLoption.</t> <t hangText="LLADDR">Link-layeroption.</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 LLADDRoption.</t> <t hangText="server">Aoption.</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 serverfunctionalityfunctionality, as described in <xreftarget="RFC8415"/>target="RFC8415"/>, and supports the new options(IA_LL and LLADDR)specified in thisdocument.document (IA_LL and LLADDR). The server may or may not support IPv6 address assignment and prefix delegation as specified in <xreftarget="RFC8415"/>.</t> </list> </t>target="RFC8415"/>.</dd> </dl> </section> <sectionanchor="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 clientmode,mode and (ii) direct client mode.</t> <sectionanchor="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 clientandthat requests that available DHCP serverstoassign one or more addresses (an addressblock),block) for the DHCP client tobethenassigned for use byassign to the finalend-devices.end devices to use. Large-scale virtualization is one application scenario for proxy client mode. In suchenvironmentsenvironments, this entity is often called ahypervisor"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 addressusage.use. Some obsolete VMs will bedeleted anddeleted; their addresses are potentially eligible for reuseforby new VMs.</t> </section> <sectionanchor="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 clientandthat requests that available DHCP serverstoassign one or more addresses (an address block) for its own use. This usage scenario is related toIoT, as described earlierIoT (see <xref target="intro"/>). Upon first boot, for eachinterfaceinterface, the device uses a temporary address, as described in <xref target="IEEEStd802.11"/>or to be described inand 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 interfacesMUST NOT<bcp14>MUST NOT</bcp14> use alink-layer based DUID (DHCPlink-layer-based DHCP UniqueIdentifier).Identifier (DUID). For more details, refer toSection 11 of<xreftarget="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 beused,used or may require the administrator to adjust the configuration of the switch(es) to allow a change in address.</t> </section> </section> <sectionanchor="mechanism" title="Mechanism Overview">anchor="mechanism"> <name>Mechanism Overview</name> <t>Inallthe 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 withaan IA_LL option to all available DHCP servers. That IA_LL optionMUST<bcp14>MUST</bcp14> includeaan LLADDR option specifying the link-layer-type andlink-layer-lenlink-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'sresponseresponse, as governed by <xref target="RFC8415"/>. If necessary, the client sends a Requestmessage andmessage; 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 (seeSection 7.7 of<xreftarget="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 inSection 7.7 of<xreftarget="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 (seeSection 18.2.7 of<xreftarget="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 typicallifecyclelife cycle of one or more leases.</t> <t>Confirm andInformation-RequestInformation-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 mechanismSHOULD<bcp14>SHOULD</bcp14> use the Rapid Commitoptionoption, as specified inSection 5.1Sections <xref target="RFC8415" section="5.1" sectionFormat="bare"/> and18.2.1<xref target="RFC8415" section="18.2.1" sectionFormat="bare"/> of <xreftarget="RFC8415"/>target="RFC8415"/>, to obtain addresses with a2-messagetwo-message exchange when possible.</t> <t>Devices supporting this proposalMAY<bcp14>MAY</bcp14> support the reconfigure mechanism, as defined inSection 18.2.11 of<xreftarget="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 ofReconfigureReconfiguration Key Authentication Protocol(See Section 20.4 of(see <xreftarget="RFC8415"/>),target="RFC8415" sectionFormat="of" section="20.4"/>), small-footprint devices may choosetonot 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, overtimetime, 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.ThereforeTherefore, the mechanism should operate on addressblocks,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, relayinfrastructureinfrastructure, 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-layeraddresses,addresses but not IPv6 addresses or prefixes.</t> </section> <sectionanchor="Information-Encoding" title="Information Encoding">anchor="Information-Encoding"> <name>Information Encoding</name> <t>A clientMUST<bcp14>MUST</bcp14> sendaan 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 specifiedaddress<!-- (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 clientMUST<bcp14>MUST</bcp14> set the valid-lifetime field to 0 (this fieldMUST<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 optionin the message.inside. The IA_LL optionMUST<bcp14>MUST</bcp14> containaan LLADDRoptionoption, 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 serverMAY<bcp14>MAY</bcp14> take into consideration the address block requested by the client in the LLADDR option. However, the serverMAY<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 addressthan 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 anyaddressesaddresses, itMUST<bcp14>MUST</bcp14> return the IA_LL option containing a Status Code option (seeSection 21.13 of<xreftarget="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 optionsMUST<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 oneserverserver, as defined inSection 18.2.9 of<xreftarget="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 clientMUST<bcp14>MUST</bcp14> process the address block(s) returned in the Advertise, rather than what it included in theSolicit,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 clientMUST 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 serverMAY<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. ItMUST<bcp14>MUST</bcp14> restart its T1 and T2 timers using the values specified in the IA_LL option.</t> <t>The clientMUST<bcp14>MUST</bcp14> use the address block(s) returned in the Reply message, which may be a smaller block(s) orwithmay 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 (seeSection 18.2.1 of<xreftarget="RFC8415"/>).</t>target="RFC8415" sectionFormat="of" section="18.2.1"/>).</t> <t>A client that changes its link-layer address on an interfaceSHOULD<bcp14>SHOULD</bcp14> follow the recommendations inSection 7.2.6 of<xreftarget="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 inSection 18.2.4 of<xreftarget="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 containingaan LLADDR option for the address block being renewed. The server responds with a Reply message that contains the renewed address block. The serverMUST 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 addressMUST 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 newVMs --VMs), itMUST<bcp14>MUST</bcp14> send an IA_LL option with a differentIAIDIdentity Association IDentifier (IAID) to create another "container" for more addresses.</t> <t>If the client is unable toRenewrenew before the T2 timer elapses, it starts sending Rebindmessagesmessages, as described inSection 18.2.5 of<xreftarget="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 clientMUST<bcp14>MUST</bcp14> release thewholeblock 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 inSection 18.2.7 of<xreftarget="RFC8415"/>.</t> <t>Note: Iftarget="RFC8415" sectionFormat="of" section="18.2.7"/>.</t> <t>Note that if the client is releasing the link-layer address it is using, itMUST<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 clientMUST<bcp14>MUST</bcp14> use another address (such as the one originally used to initiate DHCPv6 to provide an allocated link-layer address).</t> </section> <sectionanchor="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> <sectionanchor="IA_LL" title="Identityanchor="IA_LL"> <name>Identity Association for Link-Layer AddressesOption">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> <figurealign="center" anchor="ia-ll-syntax" title="IA_LLanchor="ia-ll-syntax"> <name>IA_LL OptionFormat">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-optionsfield.</t> <t hangText="IAID">Thefield.</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 unsignedinteger.</t> <t hangText="T1">Theinteger.</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. Avariable lengthvariable-length field (12 octets less than the value in the option-lenfield).</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 (seeSection 21.13 of<xreftarget="RFC8415"/>)target="RFC8415" sectionFormat="of" section="21.13"/>) in the IA_LL-optionsfield. </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 consideredas havingto 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 fieldsMUST<bcp14>MUST</bcp14> be set to 0. The serverMUST<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 clientMUST<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 perSection 7.7 of<xreftarget="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 clientMUST<bcp14>MUST</bcp14> follow the rules defined inSection 14.2 in<xreftarget="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 includeaan LLADDR option in a Solicit or Request message, the serverMUST<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> <sectionanchor="LLADDR" title="Link-Layeranchor="LLADDR"> <name>Link-Layer AddressesOption">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-optionsfieldsfield encapsulates those options that are specific to this address block.</t> <t>The format of the Link-Layer Addresses option is:</t> <figurealign="center" anchor="lladdr-syntax" title="LLADDRanchor="lladdr-syntax"> <name>LLADDR OptionFormat">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 be18.</t> <t hangText="link-layer-type">The18.</dd> <dt>link-layer-type</dt> <dd>The link-layer typeMUST<bcp14>MUST</bcp14> be a valid hardware type assigned bytheIANA, as described in <xreftarget="RFC5494"/>target="RFC5494"/>, and registered in the "Hardware Types"tableregistry athttps://www.iana.org/assignments/arp-parameters.<eref target="https://www.iana.org/assignments/arp-parameters" brackets="angle"/>. A 2-octet field containing an unsignedinteger.</t> <t hangText="link-layer-len">Specifiesinteger.</dd> <dt>link-layer-len</dt> <dd>Specifies the length, in octets, of the link-layer-address field (typically6,6 for a link-layer-type of 1 (Ethernet) and 6 (IEEE 802 Networks)). This is to accommodatelink-layerslink layers that may have variable-length addresses. A 2-octet field containing an unsignedinteger.</t> <t hangText="link-layer-address">Specifiesinteger.</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 clientMAY<bcp14>MAY</bcp14> send a special value to request any address. Foralink-layertype oftypes 1 and 6, see <xref target="Information-Encoding"/> for details on this field. A link-layer-len length octet field containing anaddress.</t> <t hangText="extra-addresses">Specifiesaddress.</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. Forexample: link-layer-address:example, link-layer-address 02:04:06:08:0a and extra-addresses 3designatesdesignate a block of4four addresses, starting from 02:04:06:08:0a and ending with 02:04:06:08:0d (inclusive). A 4-octet field containing an unsignedinteger.</t> <t hangText="valid-lifetime">Theinteger.</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 unsignedinteger.</t> <t hangText="LLaddr-options">Anyinteger.</dd> <dt>LLaddr-options</dt> <dd>Any encapsulated options that are specific to this particular address block.CurrentlyCurrently, 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 fieldMUST<bcp14>MUST</bcp14> be set to 0. The serverMUST<bcp14>MUST</bcp14> ignore any received value.</t> <t>In a message sent by a server to a client, the clientMUST<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 perSection 7.7 of<xreftarget="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> <sectionanchor="selecting-addresses" title="Selectinganchor="selecting-addresses"> <name>Selecting Link-Layer Addresses for Assignment to anIA_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 serverSHOULD<bcp14>SHOULD</bcp14> follow the steps inSection 13.1 of<xreftarget="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 <xreftarget="IEEEStd802c"/>): <list hangIndent="4" style="hanging"> <t hangText="1.">Servertarget="IEEEStd802c"/>):</t> <ol spacing="normal" type="1"> <li>Server administratorsSHOULD<bcp14>SHOULD</bcp14> follow the IEEE 802 Specifications withregardsregard 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 the2^42 bitboundary 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"/>). ClientsMUST<bcp14>MUST</bcp14> reject assignments where the assigned block would cross this boundary (theyMUST<bcp14>MUST</bcp14> decline the allocation--- seeSection 18.2.8 of<xreftarget="RFC8415"/>). </t> <t hangText="3.">Atarget="RFC8415" sectionFormat="of" section="18.2.8"/>). </li> <li>A serverMAY<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. ThisMAY<bcp14>MAY</bcp14> includeoptions, such asoptions like those specified in <xreftarget="I-D.ietf-dhc-slap-quadrant"/>.</t> </list> </t>target="RFC8948" format="default"/>.</li> </ol> </section> <sectionanchor="iana" title="IANA Considerations">anchor="iana"> <name>IANA Considerations</name> <t>IANAis requested to assignhas assigned the OPTION_IA_LL(tbd1)(138) option code from theDHCPv6"Option Codes" subregistry of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained athttp://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>IANAis requested to assignhas assigned the OPTION_LLADDR(tbd2)(139) option code from theDHCPv6"Option Codes" subregistry of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained athttp://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> <sectionanchor="security" title="Security Considerations">anchor="security"> <name>Security Considerations</name> <t>SeeSection 22 of<xreftarget="RFC8415"/>target="RFC8415" sectionFormat="of" section="22"/> andSection 23 of<xreftarget="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 inSection 22 of<xreftarget="RFC8415"/>, "DHCPtarget="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 aresult." Inresult.</t></blockquote> <t>In some network environments, it is possible to securethemthem, as discussed later inthat 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 DHCPserver.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 implementationsSHOULD<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> <sectionanchor="privacy" title="Privacy Considerations">anchor="privacy"> <name>Privacy Considerations</name> <t>SeeSection 23 of<xreftarget="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 <xreftarget="RFC7844"/>target="RFC7844"/>, can also be used to improve anonymity by minimizing what is exposed.</t> <t>As discussed inSection 23 of<xreftarget="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 prefixdelegationdelegation, 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 Std802 </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 Informationtechnology - Telecommunicationstechnology--Telecommunications and information exchange between systems Local and metropolitan areanetworks - Specificnetworks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)Specifications, IEEE Std 802.11Specifications </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 AreaNetworks: OverviewNetworks:Overview andArchitecture, AmendmentArchitecture--Amendment 2: Local Medium Access Control (MAC) AddressUsage, IEEE Std 802c-2017Usage </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 AddressAssignment </title> <author /> <date />Assignment</title> <author> <organization>IEEE</organization> </author> </front> </reference> </references> </references> <sectionanchor="IEEE802cSummary" title="IEEEanchor="IEEE802cSummary"> <name>IEEE 802cSummary">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 802cspecificationspecification, which defines a new optional "Structured Local Address Plan (SLAP) that specifies different assignment approaches in four specified regions of the local MAC addressspace."space". Under this plan, there are4four 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"/> <figurealign="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 IdentifierType</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>ExtendedType</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 addressesare based on an assigned Company ID (CID), which is24-bits24 bits (including the M, X, Y, and Z bits) for 48-bit MAC addresses. This leaves24-bits24 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 IEEERA.</t> <t>StandardRegistration Authority (RA).</t> <t>MAC addresses derived from a Standard Assigned Identifier (SAI)derived MAC addressesare 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 addressesare 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>